SCHED_ULE and nice still ignored

Bruce Evans bde at zeta.org.au
Sat Jan 31 21:07:25 PST 2004


On Sat, 31 Jan 2004, Robert Watson wrote:

> On Sun, 1 Feb 2004, Andy Farkas wrote:
>
> > Steve Kargl wrote:
> >
> > > Seems to work for me.  You need to describe your problem better.
> >
> > sched_ule broke about a week ago. The following example shows an idle 4
> > CPU SMP box running -current from 2 days ago. Note the CPU percentages
> > for the idle threads:
>
> The load average measurement appears to be broken, regardless of
> scheduler.  The best thing for now, until load average measurement is
> fixed (hopefully RSN) is to ignore load as a measure of system "business".

s/appears to be/is/.  It was broken by converting loadav() to a kthread.
Every process that uses timeouts a lot is counted as being ready to
run a lot even if it does nothing except sleep waiting for timeouts to
wake it up.  E.g.:

	for (;;)
		usleep(1);

Due to the limited resolution of usleep(), a process doing this wakes up
every 2 clock ticks.  loadav() wakes up every 5+-epsilon seconds and sees
the process an average of half the time (loadav() uses some jitter, else
it might sync perfectly with the above and always see it or never see it).

If you watch things with top, then top's timeouts act similarly.  top's
default update interval is 2 seconds and this tends to sync with loadav()
every fith or tenth loadav() call, so running top gives a load average
of between 0.1 and 0.2.

To get perfect sync and a load average of 1.0 for a process doing
nothing except sleep, change the above to use setitimer() with a small
nonzero interval so that the timeout occurs every clock tick.

> However, the niceness issue is separate.  ULE seems to be treating
> niceness as a proportional scheduling priority, whereas 4BSD treats
> niceness more like realtime priority levels...

4BSD actually uses a proportional scheduling too, with smaller differences
bewteen the proportions (too small) in -current.  ULE is supposed to use
proportions closer to those in RELENG_4 (these are good for user nicenesses
but a bit too large for niceness differences >= 20).  My version of 4BSD
is table-driven and I normally use a table with proportions
2^(niceness_difference / 4.0).

Bruce


More information about the freebsd-current mailing list