Re: ULE nice behavior fixed.

On Thu, 3 Apr 2003, Bruce Evans wrote:

> On Thu, 3 Apr 2003, Daniel O'Connor wrote:
>
> > On Wed, 2 Apr 2003 16:24, Jeff Roberson wrote:
> > > It probably still needs some tweaking but it seems to be MUCH better now.
> > > New algorithm entirely.
> > >
> > > nice +20 processes will not run if anything else wants to.
> > >
> > > idleprio is still not working correctly.  bde reports that this causes a
> > > 3% perf degradation for buildworld.
> >
> > Isn't nice +20 == idle prio then?
> >
> > My understanding was that idle prio didn't run unless nothing else wanted the
> > CPU which is what you describe nice +20 as doing :)
>
> Not quite:
> - there are 32 different idle priority classes.  All of them give infinitely
>   lower (numerically, non-infinitely higher) priority than each other and
>   nice +20.
> - nice +20 should only only gives infinitely lower priority relative to nice
>   +0 or +1.  I hope SCHED_ULE implements this and not what the above says.
>   Otherwise, nice +20 would just be a 33rd idle priority class.  Actually,
>   I plan to deprecate rtprio(2) and make nice +31 through +52 correspond to
>   the 32 idle priority classes.
>

It implements idle prio as a seperate run queue that is only checked when
there is nothing to do, not even nice +20.  It is also not hard bound to
nice +20.  Only ksegs with nice values that are within 20 of the least
nice process are given slices.  The slices size is inversely proportional
to the distance of the ksegs nice from the least nice kseg.

It ended up being fairly clean.  I do hope you'll look it over some time.

Cheers,
Jeff