Date: Sun, 11 Jun 2000 17:20:04 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Brian Fundakowski Feldman <green@FreeBSD.ORG> Cc: "Jacob A. Hart" <c9710216@studentmail.newcastle.edu.au>, Doug Barton <DougB@gorean.org>, Sheldon Hearn <sheldonh@uunet.co.za>, FreeBSD-CURRENT <freebsd-current@FreeBSD.ORG> Subject: Re: Scheduler changes? Message-ID: <200006111520.RAA11260@info.iet.unipi.it> In-Reply-To: <Pine.BSF.4.21.0006111105260.28560-100000@green.dyndns.org> from Brian Fundakowski Feldman at "Jun 11, 2000 11:10:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, i understand that this means maybe a somwthat large change in the system, but what do you think if we have a lok at implementing the CPU scheduler using weights instead of strict priorities ? Do we have parts of the kernel which rely on priority to implement locking etc ? This would not be too different from what the EclipseBSD people did, and the code i recently committed to dummynet can be easily reused to this purpose, and it is efficient. With a little bit of guidance (I am not too familiar with that area of the code) i think we can do something good with little effort. cheers luigi > 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 > 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?200006111520.RAA11260>