Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Jun 2000 11:10:58 -0400 (EDT)
From:      Brian Fundakowski Feldman <green@FreeBSD.org>
To:        "Jacob A. Hart" <c9710216@studentmail.newcastle.edu.au>
Cc:        Doug Barton <DougB@gorean.org>, Sheldon Hearn <sheldonh@uunet.co.za>, FreeBSD-CURRENT <freebsd-current@FreeBSD.ORG>
Subject:   Re: Scheduler changes?
Message-ID:  <Pine.BSF.4.21.0006111105260.28560-100000@green.dyndns.org>
In-Reply-To: <20000611200322.A236@carcass.au.hartware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <c9710216@studentmail.newcastle.edu.au>
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006111105260.28560-100000>