[RC5] Re: dnetc, nice and the idle loop of Linux

Peter Cordes peter at llama.nslug.ns.ca
Thu Feb 3 19:40:27 EST 2000

On Thu, Feb 03, 2000 at 06:00:05PM +0100, Bjoern Labitzke wrote:
> Hi...
> * Peter Cordes (peter at llama.nslug.ns.ca) [000202 19:27]:
> | we're talking about facts this time, not opinions.  Hehe, what I want to
> | figure out is how to get linux to run dnetc in its idle loop instead of just
> | scheduling it at low priority.  Then it might be able to give up _all_ the
> | CPU time to procs that wanted it.
> This is depends only on the implementation of the scheduler of the OS. I use
> NetBSD and here a +20 nicelevel means, that the process gets no CPU time as 
> long as other processes with nice levels <=0 need it.

 On Linux, nice processes get less CPU, but they still get some, to avoid
starvation.  Priority (which is separate from niceness, and is adjusted
continuously by the scheduler) is determined in part by how much CPU time a
process got last tick, so a starving process will have its priority
increased, even if it's running at the maximum niceness.  Solaris does this
too.  On these systems, if more than one normal priority process wants the
CPU, the nice process gets even less time.

 Have you done experiments to verify that NetBSD's scheduler almost
totally starves processes running at maximum niceness?  I used 
time dnetc -benchmark > /dev/null
to test.  (the benchmark results don't tell you how much less CPU time the
benchmark process is getting, because it goes by user time, not elapsed
time, last time I tried it.)  Dividing the elapsed time without any crunchers 
by the elapsed time with dnetc running in the background will give about ~90%.

e.g. (on x86 Linux 2.2.14)
llama:~/dnet$ time ./dnetc -benchmark >/dev/null

real    1m1.360s
user    0m56.210s
sys     0m0.030s
llama:~/dnet$ ./dnetc -pause
dnetc: 3 distributed.net clients were paused. 0 failures.
llama:~/dnet$ time ./dnetc -benchmark >/dev/null

real    0m55.987s
user    0m55.940s
sys     0m0.030s
llama:~/dnet$ ./dnetc -unpause
dnetc: 3 distributed.net clients were unpaused. 0 failures.

55.987 / 61.360 = .912434810
so dnetc was using 1-0.912 = 8.7% of the CPU, leaving 91.2 % of the CPU time
for dnetc -benchmark so it took 1/0.912 times longer for it too finish.

 This is supported by results from top:
11079 peter     15   0   724  724   568 R       0 90.0  1.1   0:14 dnetc
  466 peter     19  19   488  356   296 R N     0  8.0  0.5 27138m dnetc
11077 peter      3   0  1064 1064   628 R       0  1.5  1.6   0:00 top

 (PRI is the dynamic priority, and NI is the niceness.  (linux nice values
go from -20 to +19).

 (top uses some of the CPU time too.  I didn't run anything else during the
dnetc -benchmark tests.)

> I don't know specifics
> about the diverse Linux distributions, but I know that there exists a patch to
> get this behaviour for Linux as well.

 Dists don't matter.  All use the same kernel.  (different dists install a
different kernel version by default, but I and most other hackers upgrade to
the latest kernel and compile that.)
 I'd like to find that patch you mention.  Anyone on this list know where it

> Hmm, is there a list archive of this list?

There's an archive but no search (that I found, in the couple minutes I
looked at http://lists.distributed.net/ anyway.)  If anyone on the list can
point me to the patch, I'd like to take a look at it.

 BTW, thanks for the info.

#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ;  e-mail: X(peter at cordes.phys. , dal.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list