Significant Interactivity Boost in Linux Kernel

An anonymous reader writes "The Linux kernel team is at it again. Linux creator Linus Torvalds recently proposed a patch to offer interactive processes a boost, greatly benefiting the X desktop, as well as music and movie players. O(1) scheduler author Ingo Molnar merged Linus' patch into his own interactivity efforts, the end result nothing short of amazing... The upcoming 2.6 kernel is looking to be a desktop user's dream come true."

Comments

for all you...

[Anonymous Coward]

bashing linux/x/kde/whatever speed, I'm willing to bet you've never doen a full build (ala Gentoo) and actually optimized it for your system...have you? KDE 3.1 is as fast or faster than windows XP on my 1ghz box...it took a while to build, but it's well worth it.

Re:huh?

[arvindn]

Kernel Dev's Gone Wild volume 3

Well, here is Linus replying to Molnar's post:

From: Linus Torvalds
Subject: Re: [patch] "HT scheduler", sched-2.5.63-B3
Date: Thu, 6 Mar 2003 09:03:03 -0800 (PST)

On Thu, 6 Mar 2003, Ingo Molnar wrote:
>
> the whole compilation (gcc tasks) will be rated 'interactive' as well,
> because an 'interactive' make process and/or shell process is waiting on
> it.

No. The make that is waiting for it will be woken up _once_ - when the
thing dies. Marking it interactive at that point is absolutely fine.

> I tried something like this before, and it didnt work.

You can't have tried it very hard.

In fact, you haven't apparently tried it hard enough to even bother giving
my patch a look, much less apply it and try it out.

> the xine has been analyzed quite well (which is analogous to the XMMS
> problem), it's not X that makes XMMS skip, it's the other CPU-bound tasks
> on the desktops that cause it to skip occasionally. Increasing the
> priority of xine to just -1 or -2 solves the skipping problem.

Are you _crazy_?

Normal users can't "just increase the priority". You have to be root to do
so. And I already told you why it's only hiding the problem.

In short, you're taking a very NT'ish approach - make certain programs run
in the "foreground", and give them a static boost because they are
magically more important. And you're ignoring the fact that the heuristics
we have now are clearly fundamentally broken in certain circumstances.

I've pointed out the circumstances, I've told you why it happens and when
it happens, and you've not actually even answered that part. You've only
gone "it's not a problem, you can fix it up by renicing every time you
find a problem".

Get your head out of the sand, and stop this "nice" blathering.

Linus

OK, maybe not gone wild as in baring their breasts, but certainly gone wild as in no-holds-barred flamage :)

Linus discovers priority inversions

[Animats]

What's being described here is called a priority inversion, where a high-priority task makes a request of some service running at a lower priority and gets hung up behind it. Real-time programmers have been dealing with this for decades, with varying degrees of success. A priority inversion bug caused problems with the Mars Pathfinder mission, and had to be patched remotely.

There are various solutions to this problem. It sounds like the Linux kernel people are trying priority inheritance via the messaging system (local sockets). QNX has had that for over a decade. Because QNX does almost everything, including all I/O, by message passing, it has to do this right. In the UNIX world, message-passing was added quite late, in BSD, and X is one of the few interactive programs that uses socket communication on the local machine. Sockets are used mostly to talk across the network. So support for time-critical local sockets isn't very good. UNIX pipes were the original UNIX interprocess communication mechanism, and they were intended as batch-like devices. Sockets look, and work, a lot like pipes. This legacy is the real cause of the problem.

Of course, the reason Linux users actually want this feature is so that they can play their pirated MP3s in the background while using X-windows.

Re:Simply More Evidence

[WNight]

Not quite right. Every multi-tasking system since the first few in the 70s has had the concept of running interactive apps with a higher priority. It's a very obvious improvement.

The non-obvious improvements are things like making the applications that depend on, or are depended on, by the interactive app, run faster. There are also additional tweaks to this that that are being considered such as giving interactive programs a smaller time-slice, but more of them, so it'll do things like paint the windows properly in respose to your movements, but it won't bog the rest of the system down.

Technically, scheduling tweaks do add to code complexity, but only in such a tiny way. Linus's patch was five lines. And Linus is very concerned with making sure patches are self-contained and, when possible, aren't spread out, a few lines in many different areas. He's got a very good, very "correct" attitude about design. It comes from him being happy with Linux for years now, he's not rushing to any specific point so it becomes useful. He's willing to put the time in to do it right.

Anyways, this is to say that most kernel patches don't lead to complexity, most decrease the complexity of the code. Linus has often sent patches back to be done the "right way" instead of allowing a hack. This tweak is so small and self-contained that it can't really be said to add complexity to anything.

Re:FINALLY! Thank you!

[Trolling4Dollars]

This example perfectly illustrates what linus was having problems with when Ingo suggested that users just nice X up. It hides the problem, but doesn't actually fix it. Windows XP plays tricks on users to make them think that it's faster than Win2K or even NT. It loads the GUI earlier than the previous OSes, but there is still a lot of shit happening on the system in the background when you first get to the desktop (services starting, background apps loading, etc...). This is what causes the delay in response to clicking on the Start button. To prove this to a friend with Linux, I set X to start up a lot earlier and disabled a few of the non-critical services in the init scripts and compiled a custom kernel. Total APPARENT boot time from "Joe User's" perspective was about 30 seconds. I have to wonder if it would be a hell of a lot faster with this new patch. The thing is that these changes DON'T actually make the system faster at all. It's pretty much the same as before, but the end-user experience is that it APPEARS faster. That seems to be what a lot of people miss in this discussion.