From owner-freebsd-current Sun Jun 11 8:18:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id AAFDC37BBD9; Sun, 11 Jun 2000 08:18:40 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id RAA11260; Sun, 11 Jun 2000 17:20:04 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006111520.RAA11260@info.iet.unipi.it> Subject: Re: Scheduler changes? In-Reply-To: from Brian Fundakowski Feldman at "Jun 11, 2000 11:10:58 am" To: Brian Fundakowski Feldman Date: Sun, 11 Jun 2000 17:20:04 +0200 (CEST) Cc: "Jacob A. Hart" , Doug Barton , Sheldon Hearn , FreeBSD-CURRENT X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > 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