lock breaking preemptible kernel

Matthias Benkmann matthias at winterdrache.de
Wed Dec 5 12:20:49 PST 2001

On 5 Dec 2001, at 10:22, Ian Molton wrote:

> Actually, thats just not true - compiling kernels on a loaded box is often
> quite a bit quicker with the pre-empt patch.
> what it does do (other than improve latency) is keep one task from hogging
> the CPU if its stuck in the kernel for a long time (perhaps in a new /
> badly written / inefficient driver).

You're actually telling me there are drivers that do busy waiting in the 
Linux kernel?  Because that is the only situation where the latency patch 
would help batch jobs, because it would cause CPU time to be used that is 
otherwise just wasted. I had assumed that any kind of i/o would put the 
process into the blocked state and give the CPU to another process till 
i/o is finished. I'm sure this is the case for disk i/o. So if you don't 
use any exotic hardware in background jobs and just play an mp3 file and 
in parallel compile a kernel, I'm sure the kernel will compile slower and 
the mp3 will play smoother if the preempt patch is used. And in fact from 
what I gather this behaviour is what gets people so hyped about the 
preemption patches. No skipping for the mp3 is more important than a few 
seconds additional compile time. After all, if you actually wanted to get 
work done, you wouldn't be listening to mp3s would you ;-)


The early bird gets the worm, but the second mouse gets the cheese.

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list