Slashdot Mirror
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."
There was a time when idiots did not walk the earth.
Linux still screams, I have a single server with two gig's of ram in it that runs 100 desktops (KDE) simultaneously. Yes it indeed takes alot of ram to run all of the new software. But for a machine that runs 2200 processes that is a impressive feat. It is a dual processor box and I have yet to see it reach over 30% processor utilization, a testament to the efficency of the kernel.
Software today requires a ton of ram, this has nothing to do with efficency of the linux kernel.
Along with this goes the idiots that think there is something wrong with X. I run this stuff in a corporate environment and X windows is linux's biggest strength. Remove X Windows and I would have to eliminate our corporate use of Linux.
Got Code?
IANAKH (Kernel Hacker), but here's my understanding of it.
The kernel development team are experimenting with heuristics to determine what processes are "interactive" and to determine "how interactive" those processes are.
An interactive process is a process which spends a portion of it's time sleeping, waiting for some kind of event, and then needs cpu time quickly after the event happens.
In this case the events are user input and screen redraw requests.
So, the trick is that interactive processes don't need any more CPU time than other processes, they just need it very quickly in response to requests. Low latency.
The question is, how do you determine what processare are interactive, and how interactive they are.
They have developed a system whereby there are effectively "interactivity points" that can be given to and taken away from a process.
The act of being woken up from sleeping by an event awards you interactivity points. The act of completely using up lots of timeslices (acting like a CPU-bound process) takes away interactivity points.
With Linus's new patch, once you've reached a certain threshold of interactivity points, some of your points start going to the process that woke you up. So, if an "interactive" process is always waking up in response to an event from a certain other process, than that other process is also awarded interactivity points.
In the end, your interactivity points are taken into account when choosing which processes get the CPU.
So, with this new code, processes which are "interactive" like your X11 apps get more of the cycles they need when they need them, decreasing their latency, and making them appear to work "better."
Justin Dubs
It doesn't. It goes through a UNIX socket. There is a significant difference.
I somehow doubt there was a single reason.
Concentrating on the UNIX socket is a mistake anyway. You need some form of client/server separation; otherwise you could never run more than one client. You also need some form of synchronisation between the clients and the server; otherwise you would have two clients accessing the hardware at the same time and most video hardware would simply lockup. The synchronisation method could be locks or mutexes or message passing or sockets; X11 chose a socket because that gives you UNIX sockets (local, high speed) and TCP/IP sockets (remote, flexible) without needing to code for special cases. Network transparency "for free".
Now the real question with X11 is "who should control the hardware". With X11 they decided a single process - the server - should control the hardware. This is perhaps the serious argument against X11. There are several reasons why this hurts performance but the serious problem - the one you inelegantly complain about - is that the client has to bundle all drawing requests up and send them to the server.
But stop. What's the real problem here. It's not that the bundling had to occur. No matter what model you chose there would have to be some data bundled up and sent between client and server. The real problem is the quantity of data. In Windows the quantity is a single message which is always quite small. In traditional X11 the "message" (aka request) grows without bound. If you're passing a huge bitmap then the request will be several kilobytes. Network transparency comes at a cost.
But stop again! Is this really a problem? The answer is no. X11 is extensible. All of the problem cases - bitmaps, video, 3D - can be special-cased with extensions. So on XFree86 we have Xvideo, MITSHM and DRI. In a traditional X11 model these guys would have stuffed the pipe to overflow and everything would have gone to shit. In modern XFree86 there is a second path that bypasses the pipe. You'll notice that DRI even allows the client to directly access the hardware! Network transparency is still there but can be bypassed on a needs basis. Perfect.
Now your argument shouldn't be "why do we need a client/server model" but "could we use something faster than sockets". The answer is no. There has already been work done by the XFree86 team where they tried a shm transport. It's no faster. Linux sockets are simply too quick. There's no reason to think that message passing would be any faster: effectively the X11 socket is a highly tuned message passing API. The platform independent nature of X11 means you'd need to use a platform independent message passing API. That probably means RPC or CORBA; X11 is going to be faster than either of those.
Anyway, my point from all of this is that the performance problems you complain about are being fixed. The developers are not idle and they are not stupid (far from it). If you wanted somebody to make your desktop faster then you could do no better than to put your trust in the current XFree86 developers team. They are a truly remarkable group of developers. They are not ignoring the performance problems. Give them some credit for understanding the depth of the issues rather than the superficial "why does XFree86 use TCP/IP?" misunderstanding that tries to pass for constructive criticism.