From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 23:08:28 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 643C937B401 for ; Wed, 2 Apr 2003 23:08:28 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E8843FAF for ; Wed, 2 Apr 2003 23:08:27 -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 h3378F619753; Thu, 3 Apr 2003 02:08:17 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 3 Apr 2003 02:08:15 -0500 (EST) From: Jeff Roberson To: Bruce Evans In-Reply-To: <20030403154330.P29472@gamplex.bde.org> Message-ID: <20030403020547.H64602-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: ULE nice behavior 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: Thu, 03 Apr 2003 07:08:28 -0000 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