Kernel Summit: Desktop performance [LWN.net]

This article is part of LWN's 2004 Kernel Summit coverage.

Robert Love talked about how to improve Linux desktop performance. He noted that many server workloads are relatively predictable. Accordingly, Linux systems support such workloads well. Desktop workloads, instead, are more variable and harder to get right. It was also noted, however, that some desktop programmers need to keep the hardware's capabilities a little more in mind when they design their systems. The tendency of both KDE and GNOME to open incredible numbers (thousands) of little files as they start up hurts performance, for example, and there is little that the kernel can do about it.

Boot time in general was an issue. Windows XP, it was pointed out, gets a login screen up in a fraction of the time Linux requires. The fact that the login screen is a false front, with the rest of the system still initializing behind it, doesn't really change things. Linux distributions could start by firing off the X server sooner in the boot process, but more than that will be needed to make big differences in the time it takes to get a Linux system started. A few schemes for preloading needed data from disk are in various states of development; they help a little bit, but the real problem seems to be in the CPU, not the I/O.

Scheduler latency remains an outstanding issue. Much work is being done to find out where the remaining sources of latency are in the kernel; once they are found, they can usually be fixed in a hurry. The general consensus seems to be that, for the purposes of desktop use, the maximum permissible latency is about 1ms. There are numerous code paths in the kernel which do not, yet, meet that standard.

Desktop systems need better information from the kernel, in the form of event notifications. It should not be necessary to poll /proc/mounts to find out that a filesystem has been added, for example. The plan appears to be the addition of a user-space notification mechanism which uses netlink. That mechanism, tied in with D-BUS, will get the necessary information to user space. One open issue is the namespace to use; a good scheme for event naming should be chosen from the outset, or a mess will certainly result later. The tentative plan is for events to be named after where the relevant source file lives in the kernel tree.

>> Next: Short topics.

Kernel Summit: Desktop performance

Posted Jul 20, 2004 20:13 UTC (Tue) by Ross (guest, #4065) [Link] (3 responses)

I have a dual-boot system at work and XP takes considerably longer to boot
than Linux. That may be because I have turned off everything I don't use
in Linux but I'm not so certain. The other annoyance with XP is that even
after you log in, you can't do anything for 5 to 10 seconds.

Kernel Summit: Desktop performance

Posted Jul 22, 2004 20:04 UTC (Thu) by jzbiciak (guest, #5246) [Link]

Only 5 to 10 seconds? I have a corp-issue XP laptop. They throw so much mandatory crap in the per-user startup folder it isn't funny. I wait a good 30 seconds or more, waiting for such stuff as:

network logon scripts
backup software (why isn't this a system service? why do I have to see it? why does it slow the laptop to a crawl whenever it runs?)
virus software (same complaint as for backup software)
firewall software (again... why not a system service?)
who knows what else?

It's really quite annoying.

Kernel Summit: Desktop performance

Posted Jul 23, 2004 19:58 UTC (Fri) by riddochc (guest, #43) [Link] (1 responses)

I must say, I'm impressed. My father's XP system is a decent 1.5 Ghz Athlon, a quarter gig of memory, and plenty of hard drive space. It takes 3 minutes from the time you hit the power button to the time you can log in. Once you're logged in, it takes another 7 or 8 *minutes* for the system to actually be in a usable state. He regularly turns on his computer, starts making coffee, logs in, and then finishes making his coffee before going back to his computer.

XP has the annoying feature that if you do something like click on the start menu while things are still being run out of the startup folder, the menu will randomly go away while the other program runs. It's as though these services require you to not be using anything while they're starting up, which suggests to me that they really should be started *before* the login screen comes up. Eh. Windows.

Perhaps this is an unusual case, but my girlfriend's mother's XP system does the same thing. Meanwhile, both my laptop and my desktop running SuSE 9.1 come up from a cold boot in under a minute and a half. I login, and WindowMaker comes up in about 2 seconds, Konsole in about 10, Emacs in 8, and Mozilla in about 20. Once the libraries are loaded, new instances are a lot snappier.

Kernel Summit: Desktop performance

Posted Aug 2, 2004 5:58 UTC (Mon) by goaty (guest, #17783) [Link]

My father's XP system is a decent 1.5 Ghz Athlon, a quarter gig of memory, and plenty of hard drive space.

There's your problem right there. XP doesn't fit in 256Mb. It's slow because it's swapping.

I personally think XP starts up amazingly quickly, given its gargantuan girth. I've sometimes wondered if Microsoft weren't doing horrible hacks like copying some DLLs straight into the page file, but surely even they wouldn't sink that low!

I too have played "Start Menu Roulette" on many an occasion. You've got to give Microsoft their props. The XP Start Menu is the only GUI widget that makes me laugh on a regular basis.