Date: Thu, 3 Apr 2003 16:15:51 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: current@freebsd.org Subject: Re: ULE nice behavior fixed. Message-ID: <20030403154330.P29472@gamplex.bde.org> In-Reply-To: <200304030931.06619.doconnor@gsoft.com.au> References: <20030402015226.E64602-100000@mail.chesapeake.net> <200304030931.06619.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030403154330.P29472>