Kernel Summit: Desktop performance
[Posted July 20, 2004 by corbet]
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.
(
Log in to post comments)