On Tue, Apr 17, 2007 at 09:33:08AM +0200, Ingo Molnar wrote: > > * William Lee Irwin III <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 16, 2007 at 11:50:03PM -0700, Davide Libenzi wrote: > > > I had a quick look at Ingo's code yesterday. Ingo is always smart to > > > prepare a main dish (feature) with a nice sider (code cleanup) to > > > Linus ;) And even this code does that pretty nicely. The deadline > > > designs looks good, although I think the final "key" calculation > > > code will end up quite different from what it looks now. > > > > The additive nice_offset breaks nice levels. A multiplicative priority > > weighting of a different, nonnegative metric of cpu utilization from > > what's now used is required for nice levels to work. I've been trying > > to point this out politely by strongly suggesting testing whether nice > > levels work. > > granted, CFS's nice code is still incomplete, but you err quite > significantly with this extreme statement that they are "broken". > > nice levels certainly work to a fair degree even in the current code and > much of the focus is elsewhere - just try it. (In fact i claim that > CFS's nice levels often work _better_ than the mainline scheduler's nice > level support, for the testcases that matter to users.) > > The precise behavior of nice levels, as i pointed it out in previous > mails, is largely 'uninteresting' and it has changed multiple times in > the past 10 years. > > What matters to users is mainly: whether X reniced to -10 does get > enough CPU time and whether stuff reniced to +19 doesnt take away too > much CPU time from the rest of the system.
I agree there. > _How_ a Linux scheduler > achieves this is an internal matter and certainly CFS does it in a hacky > way at the moment. > > All the rest, 'CPU bandwidth utilization' or whatever abstract metric we > could come up with is just a fancy academic technicality that has no > real significance to any of the testers who are trying CFS right now. > > Sure we prefer final solutions that are clean and make sense (because > such things are the easiest to maintain long-term), and often such final > solutions are quite close to academic concepts, and i think Davide > correctly observed this by saying that "the final key calculation code > will end up quite different from what it looks now", but your > extreme-end claim of 'breakage' for something that is just plain > incomplete is not really a fair characterisation at this point. > > Anyone who thinks that there exists only two kinds of code: 100% correct > and 100% incorrect with no shades of grey inbetween is in reality a sort > of an extremist: whom, depending on mood and affection, we could call > either a 'coding purist' or a 'coding taliban' ;-) Only if you are an extremist-naming extremist with no shades of grey. Others, like myself, also include 'coding al-qaeda' and 'coding john howard' in that scale. - 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/
