Thank you for the detailed explanation Linus. The sudden availability of multi-core hardware must bring up the issue "is all this processing power being used to its full potential". As you said server loads are more predictable unlike desktops, where some may surf the web while others encode 2 movies, burn a dvd and serve files to a media center all at the same time.

Linus Torvalds (torvalds@osdl.org) on 7/25/07 wrote:
---------------------------
>Shankhadeep (shank15217@gmail.com) on 7/25/07 wrote:
>>
>>Con quit because he believed that there is no enough focus
>>on desktop performance in kernel development.
>
>I disagree. I personally have always thought that the
>desktop is the most interesting niche of all - because it's
>the one that shows the most varied load usage, but also
>because it tends to be the one that has the tightest
>requirements by far (ie people notice things on a
>desktop that they would never notice anywhere else).
>
>Sound skipping is the canonical example: because people
>notice audio latencies easily in the tenth-of-a-second
>range, sound fragments are much smaller than that, and you
>can clearly hear skipping a fragment even if we're talking
>milliseconds.
>
>So millisecond latencies together with unpredictable IO,
>and often insufficient memory (do you really think that
>server loads swap under benchmarks? Think again. But it's
>normal for desktop use) makes the desktop much more of a
>challenge (and thus much more interesting) than servers.
>
>In fact, I will argue (and have argued) that the reason
>Wintel was set to kicking traditional UNIX butt a decade
>ago was exactly that traditional UNIX had left the desktop
>behind, and was often technically inferior as a result.
>
>One of the real problematic issues with the desktop loads
>is that they are often hard to quantify. Throughput is just
>a lot more easier to benchmark than latency. And the
>things that humans notice (visual and audible latency)
>are the hardest one to test for.
>
>>One of the key points was that the current cpu scheduler
>>in standard kernels isn't appropriate for desktops.
>
>Well, that's really where Con's issue is. I merged the
>improved scheduler a few weeks ago, I just didn't merge
>his version.
>
>The reason? There were things like double-blind studies
>comparing the two, and there really was no difference. And
>as a top-level maintainer, I need to not just look at
>things like that, but also at whether I can trust the
>developer to stick around and fix up the inevitable
>problems that come from big changes like that.
>
>So when I have a choice between two code bases, both of
>which perform equally well, but one of which is from the
>current scheduler maintainer (admittedly egged on by the
>fact that Con was able to improve noticeably on his older
>version) who I know is responsible, the thing really is
>pretty much a no-brainer.
>
>Con was attacking people who reported problems. Ingo (the
>author of the other patch) was trying to help them track
>down the cause of the problem.
>
>Who do you think gets his code merged?
>
>>As we are approaching quad cpu desktops in the mainstream
>>will there be a renewed focus on improving Linux
>>performance on the desktop?
>
>Quad core actually tends to make for fewer issues
>in scheduling, since you have more leeway, and simply have
>more resources to throw at it (SMT, in contrast, can make
>for some hard-to-schedule cases, because of the possible
>imbalance between threads. That exists with full cores too,
>but it's not quite as noticeable).
>
>Multi-core brings other issues, of course (ie you need to
>make sure your locking is right etc), but that's one thing
>that we've generally solved long ago.
>
>So I do think that the desktop will continue to be the area
>that really pushes the envelope (it's simply that much more
>complex than any other use), but I don't think multi-core
>is really where the issues will likely be.
>
>And I'll personally continue to consider the desktop the
>most interesting area - the way I always have. Because it's
>actually the main area I use Linux myself. I don't run any
>servers, and while I have a few embedded Linux devices,
>the desktop is where I work 99% of the time.
>
>Linus