OSNews

I think this has been a healthy experience for the kernel community. Linus made the right decision by going with the more consistent scheduler and maintainer. But more importantly, the controversy ignited the desktop enthusiast crowd and got them involved in the debate. It reminded the elite kernel hackers that they have to be responsive (no pun intended) to the desktop userbase.

Con ended up getting exactly what he and his fans wanted: a chance to air their grievances and gain exposure for their cause. The kernel community needs a real desktop lobby, so to speak, and while CK is gone (for now), he leaves behind a genuine movement that should continue where he left off. Juicy patches like swap prefetch won't go away. In fact, the political aftermath of SD may help pave a smoother path to mainline acceptance.

The fact of the matter is that there's a lot going on in the kernel for desktop users. Power management, suspend/hibernate, kernel preempt notification, wifi, firewire, and more. Much of the virtualization and process container work is useful for desktop users.

Unfortunately, though, there's a lot more we can do in the kernel to improve server workloads. The vast majority of the issues facing desktop users fall on the userspace side of the operating system. Xorg, GNOME/KDE, GCC, Parrot/Mono/Java--these are the kinds of projects with high potential payoff for desktop users.

Finally, desktop enthusiasts need to gain a better understanding of how to submit good bug reports. Distribution projects are key to making this happen. There should be a forum-like method for linking less experienced users encountering bugs with advanced users that can help them gather the information required for a quality bug report. Developers will address thorough bug reports before they track down the vague complaints.

The fact of the matter is that there's a lot going on in the kernel for desktop users. Power management, suspend/hibernate, kernel preempt notification, wifi, firewire, and more. Much of the virtualization and process container work is useful for desktop users.

What is also useful is a fast CPU-GPU combo.

"""
It reminded the elite kernel hackers that they have to be responsive (no pun intended) to the desktop userbase.
"""

Just one comment here. The elite kernel hackers *are* part of the desktop userbase. And with a fairly demanding workload, at that. Does anyone think that they do not ever do desktop things with a compile or two running in the background?

As Linus put it:

""
The fact is, I've _always_ considered the desktop to be the most important
part. And I suspect that that actually is true for most kernel developers,
because quite frankly, that's what 99% of them ends up using. If a kernel
developer uses Windows for his day-to-day work, I sure as hell wouldn't
want to have him developing Linux. That has nothing to do with anything
anti-windows: but the whole "eat your own dogfood" is a very fundamental
thing, and somebody who doesn't do that shouldn't be allowed to be even
_close_ to a compiler!
""

Linus's whole post is here:

http://lkml.org/lkml/2007/7/28/106

That's not true. Ingo himself wrote that he is a lot more interested in regression reports than praise, because this gives him the opportunity to improve the scheduler.

I think if it's smooth under WINE then it will be better native. WINE sits on top of OpenGL so actually it's a good way to get something smooth. It's not like kernel devs have done nothing for desktop users, we have udev, preemption(lower latency), Hz control, memory spit(no high mem for 1Gb reducing overhead) and now a new scheduler.

Not sure if they will go lower level since linus thinks server and desktop have profited from being the same kernel.

The memory split config option went away in 2.6.20 or 2.6.21, Linus thought it was too confusing.

I compiled 2.6.22 in slackware and memory split was there.

If you read the full thread (check out http://thread.gmane.org/gmane.linux.kernel ) you will see Ingo say that he did benchmarks in wine because wine is more complex. It requires a server / client design with stresses a scheduler (like CFS or SD) harder.

"""
Not garbage like Quake 4.
"""

The textures were a bit shabby. The conceited nerd tech guy was irritating and a bit overused. But the game was fun. Just more resource intensive than it needed to be.

You are just sad because Quake 4 doesn't run in your computer.

You are just sad because Quake 4 doesn't run in your computer.

You mean only on computers on steroids.

Actually, I'm sad because I keep playing the same game for the past 15 years and wonder why it's only the titles that change.

FPSs need to be led out behind the barn and shot.

....of some good games. Not garbage like Quake 4.

I liked Quake 4 It isn't the best game I've played but it was still very enjoyable ^^ But sure, I agree, we need some good ports

GOW for example

http://forums.epicgames.com/showthread.php?t=574826

Never played Quake 4, but judging from the other comments here it's not that bad.

I do agree though, that there needs to be more games for Linux... and more high-profile ones too if possible.

A history lesson or even reading a bit of the older threads would tell you the answer. Both SD and CFS were comparable while SD performed better in some areas and CFS in others. After CFS got merged, Ingo did some work to get a better performance with it in one specific instance (ie) those playing 3D games.

Ingo also wrote the previous 0(1)scheduler and everyone now agrees that either one of SD or CFS performs better so improvements have been made.

A "history lesson" taught me that SD exists for 2 years, and CFS since April 2007.

I'm very happy to see that the "desktop point of view" is a subject of concern for the kernel developers.

But i'm very sad to see that the lklm mantra is "Stole Idea, Recode everything".

Edited 2007-08-02 10:39

First public SD version (then called RSDL; fair scheduler) was released not that long before CFS (5 Feb vs 13 Apr 2007). It's the old staircase (which supplied Con with some ideas for RSDL) that's been out for a substantially longer time.

Edited 2007-08-02 10:57

"""
But i'm very sad to see that the lklm mantra is "Stole Idea, Recode everything".
"""

Now that we are getting past all the purely subjective and thoroughly placebo-laced "feels more responsive to me" BS and down to actual numbers, it looks like the rewrite has had some benefits. It may be that SD could be modified to do better, as the sched yield NOP patch suggests. But we'll never really know now, since SD is unmaintained.

The first public versions of each were about two months apart.

I think your characterization of the development process on lklm and cfs in particular is rather ridiculous. Con stole to the degree that Ingo did, certainly. It's not like these are the first schedulers ever written. Step back a moment...it's a good thing to have choice in terms of what makes the kernel, not a bad thing.

After reading both codes, I have to say that the Ingo's code is better (far better) than the Con's code. Ingo is a very great developer. And (I repeat) I'am very happy to see that Desktop does matter for the kernel guys.

But I also remember that Con (and others) did complain about the o(1) scheduler (for desktop/game) and Ingo ignored them. I remember that Con wrote & sent patches and Ingo ignored them. And, at last, I remember that Ingo proudly announced his CFS, coded alone and closed-door, with a short thank for Con's efforts in a readme.

I don't see Con as a poor victim, but I don't see Ingo as a perfect gentleman

Be "Completely Fair" is not only for schedulers ;-)

"""
Be "Completely Fair" is not only for schedulers ;-)
"""

I think I will forever remember Con as "that guy whose fan base turned LKML into a soap opera".

A little more talk about code and a little less gossip about personalities, people!

http://article.gmane.org/gmane.linux.kernel/563655

Edited 2007-08-02 19:04

It's quite true. More important than the "Con vs Ingo" fight, it's the final result. We now have a better scheduler for Desktop/3D applications.

My thoughts are:
- Is it the begining of a complete "desktop oriented" refactor of the kernel code ?
- Is it just a "one shot" update to calm down the "year of the linux desktop" fans ?

And, more important, does Ingo really play Quake and UT2004 ? :-)

A little more talk about code and a little less gossip about personalities, people!

Would be nice if unix would allow you to nest groups easily. Like you add users with gpasswd -a <user> <group> it would be convenient if groupadd -a <group> <group> (nesting) were possible.

Is there really overhead from using Wine APIs? It's just another API, after all. Or is it that the Wine APIs are not as optimized as some other APIs?

Anyway, I hardly see that SD dropping from 41fps to 3 fps with only one processor intensive process in the background, a 14-fold decrease, vs CFS starting at 41fps and staying at 41fps under the same conditions can be considered a "slight decrease".

Or am I misinterpreting your post? I have a feeling that maybe I am.

Edited 2007-08-02 13:52

There is some overhead; it's an added layer of abstraction. However, the overhead is almost irrelevant if you compare it to other ways of Windows "emulation".

Indeed there are some programs that benefit from Linux' better scheduling, I/O management and memory management, they will actually run faster. Not with 3D applications though; most 3D drivers are still lagging behind their Windows counterparts.

Is there really overhead from using Wine APIs? It's just another API, after all. Or is it that the Wine APIs are not as optimized as some other APIs?

------

Yes, thats my interpretation. I also think Wine does some low-level things in different than the official Win32 APIs, which might also have a performance hit.

That said the performance is acceptable to me and most who use Wine.

------

Anyway, I hardly see that SD dropping from 41fps to 3 fps with only one processor intensive process in the background, a 14-fold decrease, vs CFS starting at 41fps and staying at 41fps under the same conditions can be considered a "slight decrease".

Or am I misinterpreting your post? I have a feeling that maybe I am

------

Are you contradicting yourself?

ck1 got 3 FPS in Quake 3 at "1 loop" whereas CFS v19 got 41.

CFS is the schedular that appears to be working better according to this benchmark. Thats a good thing, no?

However, I run Q3 with an older kernel w/ SD and the performance is fine. So I don't know what this "loop" thing is.

Edited 2007-08-02 15:20

"""
ck1 got 3 FPS in Quake 3 at "1 loop" whereas CFS v19 got 41.

CFS is the schedular that appears to be working better according to this benchmark. Thats a good thing, no?
"""

Yes. That's exactly my view of the results. How does your Q3 act with a tight loop running in the background? Something like:

#!/usr/bin/env python
x = 0.0
y = 0
while True:
<space>x += 1.0
<space>y += 1
<space>x -= 1.0
<space>y -= 1

BTW, I used to run the original "Unreal" under Wine, when Windows98 and Voodoo3 was king, and and there was no Linux version of the game. Took me a whole weekend of 16 hour days to get it working right. (Sound was the last big hurdle.) But when I compared my framerate with that of Win98 users with similar settings and hardware, I actually came out ahead! And I remember being impressed by playing the whole game twice through the following week (which is hours and hours and hours of play) with only *one* crash. Also better than what Win98 people seemed to be experiencing.

Shocked the pants off me!

Of course, "notepad" crashed more often than that. Go figure! ;-)

Edit and P.S. Is it possible to format code in an OSNews post? Python kind of cares about white space, and the code snippet originally posted above will not run without proper indentation! I added the <space> placeholders instead of real spaces.

Edited 2007-08-02 15:40