Kernel engineering

Optimise your kernel for the server or desktop performance, with Col. Kernel, Ashton Mills.

It’s all too easy to think of Windows or Linux as operating systems that just work when we throw our demands at them. We know that both are designed to handle server and desktop environments, and though logically you’d assume these to be contrary, under the hood the operation of the kernel to support them can be substantially different.

It’s all about latency
If you think about it, for each and every slice of CPU time, your operating system can do only one thing. The magic that is multitasking is the brilliant management and execution of commands from multiple processes to run them, as seamlessly as possible, side-by-side. But when it comes to making sure an operating system performs as required for the two core environments of server and desktop, how the kernel does this makes all the difference.

Bandwidth reservation with Windows Media Player as an example, and the 80% task priority via multimedia scheduling. Source: Microsoft

Microsoft has made lots of noise about the advantages of Vista. When you look under the hood at just the kernel changes you can quickly see how Microsoft has worked hard on the end-user desktop experience, and also the extent to which XP, and Windows versions prior to this, have all been slowly working on the problem. And that it still isn’t completely there yet.

Linux is no different and, in many ways, is worse off. The brain boxes behind Linux kernel development are masters, but for almost two decades now the Linux kernel has been engineered and finely tuned for the market where it first got a foothold: servers. The focus in recent years on Linux for the desktop is great, and much of the work that’s been done has been on the user space (witness Ubuntu and the many changes it makes on the desktop to make Linux accessible). But under the hood, all Linux distributions are still running a kernel that was essentially designed for a server, not a desktop.

This expresses itself in the problems some users face. For example, stuttering audio playback while accessing a disk, or slowed GUI window movement under high processor loads. The problem isn’t that the kernel can’t handle the workload, it’s how the kernel has been designed to handle it.

Configuring a Linux kernel – CFS and its default ‘Interactive Desktop’ setting.

It’s a complex problem for Windows and Linux. How can you get optimum performance under both these two core environments when, for the most part, they are largely opposed?

There’s a popular maxim that states server and desktop requirements roughly correlate to a sliding scale between throughput and latency. Servers are big on throughput, while desktops are big on (low) latency. And the more you get of one, the less you get of the other. While this is true in principle, the issue can really be broken down to just latency, as lower latencies tend to equate to lower throughput.

For servers, throughput and getting work done is usually more important than latency, as well as ensuring that services (be it file, web, networking and so on) get their fair share of time in the sun. For desktops it’s somewhat the other way around – low latencies mean responding quicker to the user, and giving some tasks higher priority at the expense of others (effectively an ‘unfair’ workload) can mean a more seamless user experience where it counts.

Consequently, there is actually quite a lot that both Vista and Linux do at the kernel level to provide a better experience for the desktop user.