How nice should behave (was Re: More ULE bugs fixed.)

On Tue, 4 Nov 2003, Bruce Evans wrote:

> On Sun, 2 Nov 2003, Jeff Roberson wrote:
>
> > You commented on the nice cutoff before.  What do you believe the correct
> > behavior is?  In ULE I went to great lengths to be certain that I emulated
> > the old behavior of denying nice +20 processes cpu time when anything nice
> > 0 or above was running.  As a result of that, nice -20 processes inhibit
> > any processes with a nice below zero from receiving cpu time.  Prior to a
> > commit earlier today, nice -20 would stop nice 0 processes that were
> > non-interactive.  I've changed that though so nice 0 will always be able
> > to run, just with a small slice.  Based on your earlier comments, you
> > don't believe that this behavior is correct, why, and what would you like
> > to see?
>
> Only RELENG_4 has that "old" behaviour.
>
> I think the existence of rtprio and a non-broken idprio makes infinite
> deprioritization using niceness unnecessary.  (idprio is still broken
> (not available to users) in -current, but it doesn't need to be if
> priority propagation is working as it should be.)  It's safer and fairer
> for all niced processes to not completely prevent each other being
> scheduled, and use the special scheduling classes for cases where this
> is not wanted.  I'd mainly like the slices for nice -20 vs nice --20
> processes to be very small and/or infrequent.

idprio should be able to function properly since we have priority
propagation and elevated priorities for m/tsleep.  I believe that many
people rely on the nice +20 behavior.  We could change this and make it a
matter of user education.

ULE's nice mechanism is very flexible in this regard.  I would only have
to change one define to force the slice assignment to scale across the
whole slice range.  Although, I only have 14 possible slice values to
hand out, so small differences would be meaningless.

>
> Bruce
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>