On Wed, Apr 18, 2007 at 05:45:20AM +0200, Mike Galbraith wrote: > On Wed, 2007-04-18 at 05:15 +0200, Nick Piggin wrote: > > On Tue, Apr 17, 2007 at 04:39:54PM -0500, Matt Mackall wrote: > > > > > > I'm a big fan of fairness, but I think it's a bit early to declare it > > > a mandatory feature. Bounded unfairness is probably something we can > > > agree on, ie "if we decide to be unfair, no process suffers more than > > > a factor of x". > > > > I don't know why this would be a useful feature (of course I'm talking > > about processes at the same nice level). One of the big problems with > > the current scheduler is that it is unfair in some corner cases. It > > works OK for most people, but when it breaks down it really hurts. At > > least if you start with a fair scheduler, you can alter priorities > > until it satisfies your need... with an unfair one your guess is as > > good as mine. > > > > So on what basis would you allow unfairness? On the basis that it doesn't > > seem to harm anyone? It doesn't seem to harm testers? > > Well, there's short term fair and long term fair. Seems to me a burst > load having to always merge with a steady stream load using a short term > fairness yardstick absolutely must 'starve' relative to the steady load, > so to be long term fair, you have to add some short term unfairness. > The mainline scheduler is more long term fair (discounting the rather > obnoxious corner cases).
Oh yes definitely I mean long term fair. I guess it is impossible to be completely fair so long as we have to timeshare the CPU :) So a constant delta is fine and unavoidable. But I don't think I agree with a constant factor: that means you can pick a time where process 1 is allowed an arbitrary T more CPU time than process 2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
