Re: ULE nice behavior fixed.

On Wed, 2 Apr 2003, Sheldon Hearn wrote:

> On (2003/04/02 21:48), Bruce Evans wrote:
>
> > > Some of us have been waiting for that behaviour for a long time (long
> > > before you started working on ULE).
> >
> > Er, this is the normal behaviour in FreeBSD-3.0 through FreeBSD-4.8,
> > so you shouldn't have waited more than negative 4 years for it :-).
> > The strict implementation of this behaviour in these releases causes
> > priority inversion problems, but the problems apparently aren't very
> > important.  The scaling of niceness was re-broken in -current about 3
> > years ago to "fix" the priority inversion problems.
>
> I should have realized that "a long time" would mean different things to
> different people, with respect to HEAD.  I remember being involved in a
> flamefest on this issue a few years back.  You were involved too. :-)
>
> However, are you sure the "nice 20 only gets unwanted CPU" behaviour is
> actually what you get in RELENG_4 (as opposed to your heavily patched
> version)?

I tested RELENG_4 while replying :-).  I don't have any significant
patches in it.  "nice 20 only gets unwanted CPU" was the intended
behaviour, and it still seems to work.  I found it hard to see it
working since I used 2.5-months-noncurrent -current utilities.  I use
some hacks to unbreak things like test(1) using a syscall that doesn't
exist in RELENG_4, but the hacks don't extend to making ps or top work,
so I couldn't use them to see what the processes were doing.  Normally
I use simple tests like:

%%%
for i in 0 20
do
    nice -$i sh -c "while :; do echo -n;done" &
done
top -o time
%%%

to debug scheduling of long-running (cpu hog) processes.  If niceness
is working right, then the priority of the nice +0 should never reach
that of the nice +20 process (actually the actual priorities (actual =
displayed + PZERO) mod 4).  You can normally see what is happening by
watching top for a while and predict what will/should happen with some
practice.

Bruce