Date: Sun, 1 Feb 2004 16:07:18 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@freebsd.org> Cc: Harald Schmalzbauer <h@schmalzbauer.de> Subject: Re: SCHED_ULE and nice still ignored Message-ID: <20040201154846.E7317@gamplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1040131191144.14279A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040131191144.14279A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040201154846.E7317>