Date: Thu, 14 Oct 1999 16:05:53 -0700 (PDT) From: Ross Harvey <ross@ghs.com> To: dufault@hda.com, gibbs@caspian.plutotech.com Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, gallatin@cs.duke.edu, mjacob@feral.com Subject: Re: cvs commit: src/sys/alpha/alpha clock.c interrupt.c Message-ID: <199910142305.QAA16878@random.teraflop.com>
next in thread | raw e-mail | index | archive | help
> From owner-cvs-all@FreeBSD.ORG Thu Oct 14 11:07:51 1999 > To: Peter Dufault <dufault@hda.com> > Cc: gallatin@cs.duke.edu (Andrew Gallatin), mjacob@feral.com, > cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG > Subject: Re: cvs commit: src/sys/alpha/alpha clock.c interrupt.c > Date: Thu, 14 Oct 1999 12:06:30 -0600 > From: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> > > >> I think all this could go away if the scheduler was fixed, but I'm not > >> up to that task. > > > >Could you try the patches in PATCHES.scheduler in my home directory > >on freefall and see how it affects things? > > Although you patches fix a lot of problems and make the code clearer, > (we've been using them here at Pluto for a while now) I don't believe > they address the 'nice' problem that NetBSD fixed. Bruce understands > clock issues better than just about anyone, and I've occasionally prodded > him to review both changes as I don't feel competent enough in this area > to commit them myself. Hopefully Bruce will have time to look over the > problems so we can resolve any sticking points during FreeBSD-con. It's important to note that the problem is not restricted to alpha, it's just that the magnitude of the error there is so large it demands a fix. I don't think I have access to PATCHES.scheduler, but obviously, just cutting down the stathz for alpha like Drew did doesn't really solve the problem on alpha or affect x86 at all. Problems you probably still have: * nice levels have less and less effect at higher load average * nice +20 jobs on alpha ==or x86== probably still accumulate CPU time despite 25 years of documentation that claims nice +19 will run only "when nothing else wants to", not to mention the fact that you really do want a way to make a completely non-contending process * the nice +20 problem is probably a lot worse at high load average I may have set an all-time NetBSD record on length of commit log message; it explains about all of these issues: > revision 1.55 > date: 1999/02/23 02:56:03; author: ross; state: Exp; lines: +39 -10 > Scheduler bug fixes and reorganization > * fix the ancient nice(1) bug, where nice +20 processes incorrectly > steal 10 - 20% of the CPU, (or even more depending on load average) > * provide a new schedclk() mechanism at a new clock at schedhz, so high > platform hz values don't cause nice +0 processes to look like they are > niced > * change the algorithm slightly, and reorganize the code a lot > * fix percent-CPU calculation bugs, and eliminate some no-op code > > === nice bug === Correctly divide the scheduler queues between niced and > compute-bound processes. The current nice weight of two (sort of, see > `algorithm change' below) neatly divides the USRPRI queues in half; this > should have been used to clip p_estcpu, instead of UCHAR_MAX. Besides > being the wrong amount, clipping an unsigned char to UCHAR_MAX is a no-op, > and it was done after decay_cpu() which can only _reduce_ the value. It > has to be kept <= NICE_WEIGHT * PRIO_MAX - PPQ or processes can > scheduler-penalize themselves onto the same queue as nice +20 processes. > (Or even a higher one.) > > === New schedclk() mechansism === Some platforms should be cutting down > stathz before hitting the scheduler, since the scheduler algorithm only > works right in the vicinity of 64 Hz. Rather than prescale hz, then scale > back and forth by 4 every time p_estcpu is touched (each occurance an > abstraction violation), use p_estcpu without scaling and require schedhz > to be generated directly at the right frequency. Use a default stathz (well, > actually, profhz) / 4, so nothing changes unless a platform defines schedhz > and a new clock. Define these for alpha, where hz==1024, and nice was > totally broke. > > === Algorithm change === The nice value used to be added to the > exponentially-decayed scheduler history value p_estcpu, in _addition_ to > be incorporated directly (with greater wieght) into the priority calculation. > At first glance, it appears to be a pointless increase of 1/8 the nice > effect (pri = p_estcpu/4 + nice*2), but it's actually at least 3x that > because it will ramp up linearly but be decayed only exponentially, thus > converging to an additional .75 nice for a loadaverage of one. I killed > this, it makes the behavior hard to control, almost impossible to analyze, > and the effect (~~nothing at for the first second, then somewhat increased > niceness after three seconds or more, depending on load average) pointless. ross.harvey@computer.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910142305.QAA16878>