Subject: Re: Nice 20 process running despite needed CPU time
To: R. C. Dowdeswell <elric@imrryr.org>
From: Bjoern Labitzke <hermit@hermit.home.cs.tu-berlin.de>
List: current-users
Date: 05/02/2000 16:02:33
* R. C. Dowdeswell (elric@mabelode.imrryr.org) [000502 15:39]:
| 
| On 957225444 seconds since the Beginning of the UNIX epoch
| Bjoern Labitzke wrote:
| >
| >To summarize: Processes with a nice value of 20 don't get CPU cycles, if 
| >processes with values <=0 need them, _unless_ one or more processes with a
| >value between 1 and 18 are using cycles as well.
| >
| >It seems to me, that this behaviour is not correct. If it is the intended
| >behaviour, the setpriority man page should be changed appropriatly. Or do I
| >miss something?
| 
| I tried this with busy loops on alpha and I couldn't reproduce your results,
| are you sure that lame isn't being niced to 4 because of its accumulated CPU
| time?

ps -axu output:

USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
hermit     409 88.6 10.6   620 13780 E4  R+    3:45PM    4:46.00 ./setiathome -n
hermit     427  6.6  0.9  1108 1220 E3  DN    3:47PM    0:12.06 cvs -d anoncvs@
hermit     151  2.5  0.3   604  384 ??  RNs   3:13PM   28:40.96 /usr/local/dnet
[non-relevant rest of output cut]


ps -lax output

  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT TT       TIME COMMAND
[...cut...]
 1001   151     1   0  68 20   604  384 -      RNs  ??   28:46.02 /usr/local/dn
[...cut...]
 1001   427   425   5  -5 10  1212 1344 biowai DN   E3    0:23.18 cvs -d anoncv
 1001   409   146  33  61  0   620 12752 -      R+   E4    7:46.97 ./setiathome 


As you can see I am running setiathome for this test with nice level 0, cvs
with nice level 10 and the dnet-client with nice level 20. Before starting
the cvs client, setiathome got all the CPU cycles, dnet none. Since starting
cvs dnet gets 0.5-10.0% of the cycles!

But I could not reproduce this behaviour with two seticlients, from which I
niced one to 10. In that scenario dnet got no cycles. So perhaps the problem
occurs only, if the kernel (e.g. for file io) is used. Is this reproducable?
(For me it is, as the above example shows.) Any ideas what I might try as well
to limit the possible scope of the problem?


Bye, Bjoern

-- 
Bjoern Labitzke  <hermit@cs.tu-berlin.de>
   Use PGP! (Don't you use envelopes for your letters?)