Problem with nice

[Paul Mielke]

In article <9008072224.AA21964 at chaos.ocean.fsu.edu>,
steve at CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) writes:
> I have several problems with nice and related things.
> 
> 1. The default increment for nice on my machine seems to be 4 instead of 10
> as the manual says. i.e. "nice command" executes command with a nice
> value of 24 while  "command" executes with nice=20.
> 
> 2. "nice -increment command" does nothing at all for any value of increment.
>  Its nice value is always 20 !
> 

I have just fixed the nice(1) manual page to warn users of the csh(1)
version of nice (as other posters have suggested).

> A question about npri.
> 
> I was under the impression from previous discussions in this news group
> and from reading the manuals that if I type  "npri -h 250 -p pid" as
superuser
> then this process would be assigned a "non-degrading" priority of 250. 
> According to schedctl(2) man page this means that it is of lower
priority than
> all other processes and shouldn't interfere with ANY interactive job.
> 

The problem here is as Dr. Doelz has suggested:  just because the job
has lousy priority doesn't mean that it can't steal pages from other
jobs when it does finally get a chance to run.  In 3.3 software, we have
implemented the BSD setrlimit(RLIMIT_RSS) facility.  This allows the
Resident Set Size (the number of pages of physical memory occupied by
the process) of a process to be limited.  The combination of this
facility and setting a low non-degrading priority will allow you to
prevent the background job from stealing resources (cpu cycles or memory
pages) from higher priority processes.  This facility can be used within
NQS to establish batch queues that can execute large jobs that do heavy
paging without dragging down the performance of interactive jobs
inordinately.  When you get 3.3 software, take a look at the
setrlimit(2) manual entry and the 'limit' commands in csh(1).

The reason that you occasionally see a priority other than +250 in the
"ps -l" output for a job with "npri -h 250" is that the job will
sometimes get a kernel priority temporarily while it is executing a
system call in the kernel.  It will revert to its +250 before leaving
the kernel.  If another higher priority process is on the run queue, the
+250 guy will get descheduled as he unwinds out of the kernel from his syscall.