From owner-freebsd-current@FreeBSD.ORG Mon Nov 3 11:10:22 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8153D16A4CE for ; Mon, 3 Nov 2003 11:10:22 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8260043FA3 for ; Mon, 3 Nov 2003 11:10:20 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id hA3JACR02535; Mon, 3 Nov 2003 14:10:12 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 3 Nov 2003 14:10:12 -0500 (EST) From: Jeff Roberson To: Bruce Evans In-Reply-To: <20031103233521.L1786@gamplex.bde.org> Message-ID: <20031103140336.P10222-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: How nice should behave (was Re: More ULE bugs fixed.) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2003 19:10:22 -0000 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" >