1 2 next »

1. Fast response times
2. Version status, In brief

Kernel Log: Fast response times via process groups

by Thorsten Leemhuis

The automatic creation of process groups should keep the desktop interface responsive even when a large number of processes are making the CPU sweat. Meanwhile, the development of 2.6.37 is in full swing, and new stable kernels replace their predecessors; 2.6.35, on the other hand, has reached the end of its life.

Last week, a small patch of only about 200 lines, designed to significantly increase the interactivity of desktop applications in some situations where a CPU works to capacity, sparked considerable debate in Linux circles. The discussions about the code modification had already started a month ago; a reworked version of the patch subsequently received extra attention when Linus Torvalds gave it a lot of praise last week, commenting that his system was clearly more interactive when compiling a kernel.

The patch improves response times by automatically creating a separate process group for setsid() sessions (such as demons, real terminals or pseudo TTYs like Xterm). The resulting process group can be managed via cgroups and impacts the way the process scheduler distributes the available CPU time. This can best be demonstrated with a simplified example where a multimedia player renders a video on a single-core system while a kernel with 9 jobs is compiled in an Xterm at the same time.

Normally, the scheduler would assign 10% of the available CPU time to each task. This may not be enough for jerk-free video playback and should the desktop interface want to process, for instance, a keyboard or mouse input, this event would also have to be squeezed in, and the available time would need to be shared across eleven processes.

The patch places the compiler processes started in the pseudo terminal in their own group while the processes in the desktop environment and the multimedia player, launched from there, are placed in a different group. If both groups include processes which create full CPU loads, the process scheduler will assign 50% of the available CPU time to each group. Within each group, the processor time is distributed evenly – as a result, each compiler job will then only have 5.6%, instead of 10%, of the CPU time. This frees up processor time for the desktop environment and player software group, which should, on a typical system, be sufficient to provide jerk-free video playback and create some slack for the desktop interface to respond to mouse and keyboard inputs in a speedy fashion.

With fast CPUs, however, the player software will probably not use all of its allocated CPU time and return control to the scheduler when there are no further jobs at hand. The scheduler will, in turn, redistribute the time across other jobs, which will ultimately provide the group of kernel compiling processes with more than 50% of the CPU time – therefore, compilation should not take a great deal longer than without the automatic grouping.

However, this set-up can also be configured without the patch, even in older kernels. PulseAudio and systemd developer Lennart Poettering explained that, for a kernel that has CPU cgroups already configured, this only requires adding two calls to the Bash start-up files. Poettering considered implementing a comparable solution directly in systemd more elegant and flexible than the automatic creation of groups by the kernel. He soon implemented the required code and integrated it into systemd so that, together with an extension for the GNOME terminal, it would create groups that are similar to those created by the kernel patch. Ted Ts'o ('tytso') added that the code for desktop files could be adapted in such a way that other applications can also automatically specify their own group.

In a prolonged, and sometimes heated, discussion, the developers subsequently argued about the pros and cons of each approach. While Torvalds was rather direct himself in various places, he later calmed people down, saying that it is possible to pursue both approaches.

This currently seems to be the adopted strategy, as the maintainer of the process scheduler has indicated that he plans to submit the auto-group kernel patch for integration into 2.6.38. However, he said, he has found a code problem which is currently still being fixed. The auto-group feature can be enabled and disabled using a configuration option, so that distributions which focus exclusively on the systemd solution can simply disable the relevant kernel functions.

Most users are unlikely to care about which of the two approaches is working behind the scenes – as long as the desktop interface responds quickly and video playback is jerk-free, even when other processes are making the CPU sweat.

Next: Kernel version status

1 2 next »