|
|
Hack 90. Use CKO to Make Your Desktop Go to 11
Make your desktop quick and responsive, without making your music player skip, or your videos drop frames. A number of custom kernels are designed to increase performance in one area or another. The Con Kolivas Overloaded (CKO) kernel is probably the most famous for improving desktop performance (Con Kolivas has branched out into improving server performance, too). I also recommend the CKO kernel, because it has the frame-buffer splash patch built-in (unfortunately, it is not the type of frame-buffer splash patch needed by the Debian system boot in [Hack #8], although I expect Debian to eventually switch to the CKO boot splash patch). It also includes a more modern VESA frame-buffer driver for more recent cards. This can be useful for getting set up for the fancy login consoles [Hack #20], which uses the Qingy frame-buffer login manager. If you intend to implement any hacks that require frame-buffer support, using the CKO kernel is an easy way to prepare. This pack of hacks shows you the advantages of using the CKO kernel, and one way to tweak CKO performance in real time as you need it. Before getting started, you should be forewarned. Only one hard and fast rule applies when it comes to tweaking the performance of any kernel, whether it's a standard or a custom kernel: the rules will eventually change. The Linux standard plain-vanilla kernel has been changing rapidly in terms of the way it handles memory and swapping, for example, so what you might have learned months ago about tweaking memory swap performance in the standard kernel might be useless knowledge today. The same is also true for custom kernels, such as the CKO kernel. The best way to find out if or when the following advice becomes obsolete is to visit the Con Kolivas kernel patch home page at http://members.optusnet.com.au/ckolivas/kernel/. You can usually find the latest CKO patch set at http://kem.p.lodz.pl/~peter/cko/. The page also includes a link for patch sets for older kernels, too. Download the patch for the kernel you are using (or want to use). Apply it to your kernel this way (assuming you are using kernel Version 2.6.9, which would require the patch-2.6.9-cko3.bz2 patch): # cd /usr/src/linux-2.6.9 # bzcat / <path to> /patch-2.6.9-cko3.bz2 | patch -p1 10.4.1. Compile CKO with OptimizationsA number of CKO kernel configuration optimizations are available for
you to try, but the following should suffice for starters. The latest
2.6 kernels already include the option to make the kernel
preemptible (i.e., the kernel can be
interrupted by other tasks), but the CKO kernel adds the option to
preempt the "Big Kernel Lock."
Unfortunately, Con Kolivas doesn't explain what the
"Big Kernel Lock" is or
what advantage there is to making
it preemptible, but it sure sounds impressive, and the menu
configurator comments recommend selecting
"Yes" for this option if
you're building for a desktop. Enable this option by
selecting Processor Type and Features You can also play with the kernel's internal timer
frequency by selecting Processor Type and Features The internal timer frequency determines how long a process will run until the kernel interrupts it to see what else needs to be done. In this case, there will be 1,000 interrupts per second. This means the timer will trigger an interrupt every millisecond. You can set the number lower, but you shouldn't set it higher. A higher number (more interrupts per second) can improve or degrade performance depending on your machine's speed. If you're running anything better than a `486 on your desktop, you should be happy with the default setting of 1,000. But by all means, feel free to drop it down to 500, and see how that affects the kind of desktop computing that suits your style. You never know, the less overhead of having to interrupt the CPU so often might actually improve performance, depending on what kind of work or play you are doing. The rest of the special configuration optimizations are riskier, so stop here for now. Finish configuring the kernel for your machine's specifications, build it, and add it to your bootloader to try it out. 10.4.2. Tweaking CKO in Real TimeMemory and disk swapping are two of the most critical factors in desktop performance. A system that is heavily swapping to disk is stealing time from the tasks you want to perform without interruption, such as playing music or videos. The CKO kernel addresses this by setting a "watermark" threshold for the amount of memory applications can use before the kernel starts to do what could be intrusive swapping. The default watermark is 66% of available memory. This means Linux will allocate up to 66% of available memory to applications, and only 33% of memory for data caching. This often improves desktop performance, because Linux normally tends to use memory to cache datafiles. This makes Linux somewhat aggressive about swapping an application out to disk in favor of swapping data out to disk. If, for example, it swaps your browser to disk, you will notice a delay the next time you use your browser. The fact that CKO reserves 66% of memory for applications makes it less likely that your application will be swapped out to disk, so switching between running applications should be snappy. Sometimes, however, you will want Linux to use more memory for data than for applications. Fortunately, you can change this watermark in real time, while your system is running the CKO kernel (a roughly equivalent setting is also available in a plain-vanilla Linux kernel; see [Hack #91] ). Indeed, I often change the watermark as my work needs change throughout the day. The default of 66% is great for doing a bit of word processing while listening to music. If I build a large application, however, the compiler will run faster if it has access to a lot of memory with which to store compiled code for linking and reuse. A database also runs faster when you give it more memory to cache indexes and data. So, when I am running an intense database program or happen to be building a large program in the background, I reset the watermark to 33%, which allows the data cache-intensive applications to run at a decent pace without having one or more desktop applications become totally unusable. Here is how to change this watermark in a running CKO kernel: # echo "33" > /proc/sys/vm/mapped # echo "66" > /proc/sys/vm/mapped 10.4.3. schedtool and Isochronous SchedulingThe CKO kernel also allows you to launch applications with isochronous scheduling. Not all applications respond correctly to this technique, but those that do start at a high priority and then drop priority faster than normal. This guarantees that when they "wake up," they'll do so quickly, but they won't retain such a high priority that they starve the rest of the system and bring all other tasks to a crawl. You need a special tool to use this feature. If your Linux distribution doesn't provide the schedtool package or something with a similar name, you can get the source code from http://freequaos.host.sk/schedtool/ and compile it yourself. Unless you have multiple CPUs in your machine, compile it this way (actually, I recommend this even if you do have multiple CPUs): # make no_affinity # make install Affinity is a multi-CPU concept. It gets Linux to more likely assign a certain task to a particular CPU. Most of the time, the only people who should work with processor affinity are high-level programmers, such as SQL database programmers. Unless you really know what you're doing, it's better to let Linux decide what tasks to assign to any given processor on a multiprocessor machine. Here's how to launch an application with isochronous scheduling: $ schedtool -I -e <application name>This will start your application at a high priority, which means it should start up more quickly than usual. |
|
|
Preemptible
Kernel