Major improvement for Linux Desktop

[RealBlackStuff]

The Linux desktop is about to get a LOT faster: http://www.zdnet.com/blog/hardware/the- ... ag=nl.e589

[frankausmtank]

Interesting, thanks. According to phoronix, the patch will be in 2.6.38 at the earliest.

[Harryc]

"When Linus calls this a “real improvement,” and a “killer feature” then it’s probably time for the rest of us to shut up and pay attention to this patch"

[Neil]

Noob alert! I've been using Linux for years but never really taken the time to learn how it all works. IMHO, I don't need to know. But now it leaves me wondering....is this a "patch" that can be applied to an existing installation, or will we have to wait for the release of a patched kernel?

[Harryc]

Neil, if the patch will be applied to the 2.6.38 kernel at the earliest, you'll have to have be running that kernel (or whatever one it is eventually applied to) to use the patch. The kernels after that patch would have it applied by default.

[ThinkRob]

Sorry to burst everyone's bubble, but this patch is basically useless for the average user. It won't have much of any effect for most workloads.

[Harryc]

It won't have much of any effect for most workloads.

Please explain why ...

[ThinkRob]

Please explain why ...

Sure:

The patch assigns groups on the basis of TTY. That works great if you're doing a massively-parallel make, launched via a terminal while, say, using a browser launched from your GNOME menu. In that case, the make (and child processes) will all have the same TTY assigned and will thus be in the same process group while the browser (and your other X11 apps) will be in a different group.

But that's not what most users do. Most users use tasks that don't have a TTY assigned. In this case, all those processes will be in the same group (and thus entirely unaffected by the patch). When most people run into interactivity problems, it's often because they've got something like a torrent client doing some heavy hashing/seeding and a couple instances of some archive manager decompressing a large file -- and if they're anything like most users, all those apps won't be launched from the command line, but rather via some desktop environment like KDE or GNOME; as a result, they'll end up in the same process group, same as before.

Executive summary: the patch helps a specific type of workload. That workload is common amongst developers like as Linus and others, but relatively uncommon amongst "normal" desktop users.

[Harryc]

Now that I am paying attention to the demo videos, in both instances I see that they are running a make. Oh well, it would have been nice to see a massive improvement in the average/normal users desktop performance, although Linux is still pretty fast.

[Superego]

I see that they are running a make.

Not only that, they're running a parallel make with 64 jobs. Like ThinkRob said, not exactly what a normal user would be doing. However, I am excited as this is a good step toward getting Linux's memory management/task scheduling up to par with Windows.

[ThinkRob]

Not only that, they're running a parallel make with 64 jobs. Like ThinkRob said, not exactly what a normal user would be doing. However, I am excited as this is a good step toward getting Linux's memory management/task scheduling up to par with Windows.

? It *is* already up to par with Windows. Ever do a couple of massive project builds with VS simultaneously? The system isn't exactly responsive...

You're right though: basically the patch is useful only for a specific workload, and not a common one at that. The great irony (or perhaps injustice) of this is that when Con Kolavis produced a couple different schedulers that were/are superior to the mainline one, along with a proposal for a pluggable scheduler, he was shot down, one of the arguments being that they wanted one scheduler to work equally well for all workloads. Now it seems that they're OK with building in special case logic. Oh well.

Personally, I'm planning on merging BFS into my kernel patchset to see how it fairs. I found it pretty darn useful when I tried it a year ago, but never got around to resolving the conflicts between it and grsecurity. Now that I've got an additional year of dev. experience (and a massively different schedule) I figure I might take a crack at it some time...

[Superego]

? It *is* already up to par with Windows. Ever do a couple of massive project builds with VS simultaneously? The system isn't exactly responsive...

Sorry, I should have clarified..."up to par" wasn't the right phrase.

My point is that Linux, at it's heart, is a server OS and Windows is a desktop OS. Windows focuses more on a small number of key processes rather than Linux, which favors process creation and can scale well. The first case is great for a user who may have a few applications open that require the lion's share of resources while background processes remain....well, in the background.

The patch referenced above seems like it will move the Linux kernel a little closer to a desktop-oriented OS, like Windows.

And yes, I too hate running large makes in VS...I pretty much do all my development in Archlinux. Except it's pretty hard to play Starcraft 2 in Linux