Re: [PATCH] (Updated) Preemptible Kernel

[Robert Love]

On Thu, 2001-09-06 at 16:39, Phillip Susi wrote:
> This sounds interesting, but am I correct in assuming that this only allows 
> preemption during code that is called from user space?  For instance, it 
> would be bad to preempt an ISR or BH, right?  Actually... what happens if 
> say, the kernel called from user space is holding a lock, and gets preempted? 
>  Is there a mechanism to disable preemption while holding locks or at other 
> resources that need to be freed before another task is run?
> 
> By the way, are there any other 'modes of execution' for lack of a better 
> word, besides IRS, B, and.... 'called from user space', also for lack of a 
> better word.  Forgive me, I'm not that familiar with the Linux kernel yet.

The SMP locking mechanisms (spinlocks, readlocks, writelocks) are used
to prevent preemption for reentrancy or data validity reasons (this is
the same reason we do this for SMP).  So, there is no worry about
holding locks and whatnot.

We also don't allow preemption during interrupt handling, bottom halves,
or during execution of the scheduler itself.  So, you are correct again,
no preemption during ISRs or BHs.

At all other times, preemption is allowed.  It occurs when another task
comes due for execution -- now, even if in kernel space, we will yield
execution to the new process.  Please give the patch a try, enable
preemption, and see what you think.

Some other changes were made, too.  Certain conditions were prevented
(ie, dont return to user with a pending soft interrupt).  A preemption
counter is maintained, and the locks now modify it.  A new
TASK_PREEMPTING flag was created.

To answer your question, besides system calls (ie, `on behalf of a
process') you have ISRs, BHs, wait-queued routines (a growing number of
these), and other kernel threads (keventd, ksoftirqd, kswapd, etc) which
are typically timer/queued events anyhow.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net