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>