[LUGSB] Kernel related question

[Charles P. Wright]

On Wed, 2004-04-07 at 11:25, Mark Drago wrote:
> On Wed, 2004-04-07 at 10:38, Siddhartha Basu wrote:
> > *Kernel Preemption : What it is supposed to do? I have the idea that is 
> > supposed to geared towards desktop performance. So, if you have a kernel 
> > with this enabled in a machine which is working as a server, does it 
> > degrade the performance. How much is it needed for overall desktop 
> > performance.
> 
> Preemption is what happens when a process is running, and one with
> higher priority comes along and wants to run.  In this case, the kernel
> will "preemptively" interrupt the lower priority process and allow the
> higher priority process to run.  However, in the past, whenever code was
> running inside of the kernel (system call, etc.) the process was not
> able to be preempted.  So, if the system was running a very low priority
> process that was executing a system call, and you then start to use an
> application, the system wouldn't be able to preempt the lower priority
> process until it returned from the system call.  When you enable "kernel
> preemption", this limitation disappears.  So, it is possible to
> interrupt a low priority process running in the kernel with a higher
> priority process.  This leads into the next question...
Enabling preemption also helps on servers, particularly ones that have
to copy data back and forth alot.  There are two kernel functions,
copy_from_user and copy_to_user that move data between processes and the
kernel.  With 2.6 these can be interrupted in mid-stream.  In fact, most
things (except those that are locked) can be interrupted.  In general
this is a good thing because scheduling can be done on a more
fine-grained level.  Also things like doing encryption or other
heavy-weight CPU operations in the kernel won't increase shouldn't
increase average latency anymore.

The other important thing about preemption is that it means the kernel
locks were broken down more, so that the kernel has lower average
latency, a lower variance, but about the same worst-case latency
(because some things just need to happen under a lock).  All in all, it
should be a win for scheduling and performance at load.

> > * Interactivity: I see it more often comes up during any kernel related 
> > discussion. What exactly does it mean? Does it mean to improve desktop 
> > performace, does it hurt the performance of a server.
> 
> Interactivity is just a way of describing how quickly the system will be
> able to respond to an action.  This action may be the user clicking on a
> button, or a packet coming across the network, etc.  By having a kernel
> that is preemptible, the system will have better 'interactivity'.  This
> is the result of being able to interrupt a lower priority process
> independent of whether it is executing inside the kernel or not.  The
> problem with interactivity is that it is indirectly proportional with
> total throughput.  Since there is some overhead with switching from
> running one process to another, increased interactivity will result in
> an increase in the number of context switches, and a drop in the overall
> throughput of the system.  This is one of the challenges in designing a
> scheduler, balancing interactivity with throughput.
The new 2.6 scheduler should handle this better.  The previous scheduler
looped through all the processes in the system each time a decision was
needed (this was the "goodness" loop).  The new scheduler instead has a
lot of queues (140 * 2 * nr_cpus) and a bitmap.  You just pick the
highest priority queue and execute things in a FIFO manner.  This means
all operations are O(1) -- definately a big win for servers or for
multi-threaded applications.

Chip