From owner-freebsd-current Sun Jun 11 8:11: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9031E37B951; Sun, 11 Jun 2000 08:10:59 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 11 Jun 2000 11:10:58 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: "Jacob A. Hart" Cc: Doug Barton , Sheldon Hearn , FreeBSD-CURRENT Subject: Re: Scheduler changes? In-Reply-To: <20000611200322.A236@carcass.au.hartware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, Jacob A. Hart wrote: > On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: > > > > The diff should make a process at -20 which uses all available CPU > > schedule just slightly the ahead of a process at +20 which uses no CPU. > > A process which uses full CPU at 0 niceness would have a priority of > > 128, whereas a process using no CPU at 0 niceness would have a priority > > of 90. All processes will always have a priority less than or equal to > > 128, which is the priority at which a process with a niceness of +20 > > always runs at. A +20 process won't get better priority than anything > > else, period. Try it out, see how it works for you:) > > I tried this patch today. > > While it didn't quite fix the problem, it sure made for some interesting > pacman gameplay. ;-) Yeah, I tried it out myself. I didn't actually think beforehand (hence the testing...) why it would be bad for a process of niceness -20 to always have better than the last priority in every case... I tried it with MAME and it took a long time before my "escape" key event registered (X not getting run...). I'm thinking of ways to make the algorithm both good for people who need (err... want) low-priority background processes only to run when there's free time, and high-priority processes run but not to the exclusion of everything else. The whole scheduling algorithm proper is quite tricky to do very well; previously, it had most of the properties we want, but it also easily allowed for deadlocks. > Using idprio as Volodymyr suggested seems to be a viable workaround. You > mentioned in another message that idprio could potentially deadlock my > machine, though. Under what conditions could this happen (and how likely > is it to occur)? > > > -jake > > -- > Jacob A. Hart > Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message