Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Apr 2003 22:27:37 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Sheldon Hearn <sheldonh@starjuice.net>
Cc:        current@freebsd.org
Subject:   Re: ULE nice behavior fixed.
Message-ID:  <20030402221002.I26615@gamplex.bde.org>
In-Reply-To: <20030402115816.GN725@starjuice.net>
References:  <20030402015226.E64602-100000@mail.chesapeake.net> <20030402091300.GG725@starjuice.net> <20030402212503.N26453@gamplex.bde.org> <20030402115816.GN725@starjuice.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030402221002.I26615>