Messages in this thread |  | | Subject | Re: [PATCH] (Updated) Preemptible Kernel | From | Robert Love <> | Date | 06 Sep 2001 20:58:35 -0400 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |