[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b21f8390707292212n2c580bd8o4b7654e62cfe6786@mail.gmail.com>
Date: Mon, 30 Jul 2007 15:12:28 +1000
From: "Matthew Hawkins" <darthmdh@...il.com>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc: "George Sescher" <gesacs@...il.com>,
"CK Mailinglist" <ck@....kolivas.org>,
"Kasper Sandberg" <lkml@...anurb.dk>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: Linus 2.6.23-rc1
On 7/30/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> For example, how hard is it for people to just admit that CFS actually
> does better than SD on a number of things? Including very much on the
> desktop.
Actually in benchmarks Ingo has quoted, SD was better on the desktop
(by a small margin).
CFS is still a bit bursty, though it has significantly improved with
age. I know, I did those benchmarks. That being said, I'm really
glad to see CFS in your git tree because the new framework around it
really improves the readability of the code, and actually makes it
easier to start experimenting with scheduler improvements from an
entire scheduler like SD to minor bits like priorities.
I have one concern - my benchmarking took load average as the common
denominator and CFS alters the way the load average is calculated, so
perhaps it wasn't a fair comparison. That being said, they still
showed CFS could scale very well and SD did not, so considering we're
dealing with everything from wristwatches to BlueGene/L I believe the
right choice was made. Those arguing for the 2% improvement that SD
would give them in their environment would be better off
a) helping port SD to the new scheduler framework
b) assisting Ingo in improving CFS to meet/exceed their requirements
c) giving practical assistance to anyone doing either of the above
I'm re-learning git and using my Copious Spare Time (tm) to do what I
can - but I have to admit I'm really in over my head. But hey, if
Jeff Garzik can do it, so can I. I remember when he couldn't grok C &
now he's got control over all our data :-)
--
Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists