![[BACK]](/icons/back.gif){kind=icon}
Up to [local] / src / sys / sys
Request diff between arbitrary revisions
Default branch: MAIN
Current tag: OPENBSD_2_9_BASE
Revision 1.1 / (download) - annotate - [select for diffs], Sun Aug 15 00:07:50 1999 UTC (24 years, 9 months ago) by pjanzen
Branch: MAIN
CVS Tags: kame_19991208,
SMP_BASE,
OPENBSD_2_9_BASE,
OPENBSD_2_9,
OPENBSD_2_8_BASE,
OPENBSD_2_8,
OPENBSD_2_7_BASE,
OPENBSD_2_7,
OPENBSD_2_6_BASE,
OPENBSD_2_6
Branch point for: SMP
Adopt NetBSD fix for scheduler problems (nice was broken). From the NetBSD commit messages: 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 schedclock() 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 schedclock() mechanism === 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. [ To do: 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 weight) 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. === Other bugs === hz -> profhz in the p_pctcpu = f(p_cpticks) calcuation. Collect scheduler functionality. Try to put each abstraction in just one place.