Messages in this thread |  | | Date | Thu, 5 Sep 1996 08:03:30 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: Preempting kernel tasks |
| |
On Wed, 4 Sep 1996, David S. Miller wrote: > Alan Cox said: > Its extremely useful for high performance polled IO drivers (such > as the Quickcam). Checking if I need to reschedule costs me about > 5% performance on the camera. > > I do not argue it's usefulness, it is indeed useful as you have > shown. Other applications exist as well. What I was trying to state > was that the ends need to be acquired in a cleaner fashion, not > that the ends are unnecessary.
Like David, I do not like the idea of pre-empting kernel tasks. It implies a more complex locking setup than I'd really like.
HOWEVER, I'm all for having "user processes" in kernel mode. That's not too hard - if only implies that we have to change the way we test for "user vs kernel" a bit.
Right now, the way the kernel "return to user mode" stuff checks for user mode is to look at the saved x86 CS segment register, and looking if the protection level of the code segment we return to is non-zero (ie user). That actually means we also have to check the eflags register to see whether it's a vm86 return (because if it is, then we can't look at the CS register).
However, it would not be very hard at all to instead of checking that kind of hardware thing we'd check a software flag instead (it essentially just involves having a per-process "kernel entry" counter, and checking for zero). And then we could make a kernel thread pre-emptable by just changing the software flag to "user mode" for that thread - voila, instant "user mode behavior" together with all the kernel services..
(such a process would obviously have to be careful about not doing anything that causes re-entrancy problems, but that kind of kernel thread would be most useful for a very simple kind of loop anyway, so that's not really a problem - just don't do anything stupid).
Linus
|  |