Date: Mon, 3 Nov 2003 14:10:12 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: How nice should behave (was Re: More ULE bugs fixed.) Message-ID: <20031103140336.P10222-100000@mail.chesapeake.net> In-Reply-To: <20031103233521.L1786@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031103140336.P10222-100000>