Hi! On 13:00 Thu 05 Mar , Pranav Peshwe wrote: > On Thu, Mar 5, 2009 at 11:48 AM, Michael Blizek < > michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Hi! > > > > On 23:47 Wed 04 Mar , sahlot arvind wrote: > > > Hi All, ... > > > 2. If kernel is not preemptible then do we really need a separate kernel > > > mode stack for each and every process? I mean cannot we use a common > > kernel > > > mode stack for all and every process? I think we can because since only > > one > > > process could be in the kernel mode at a time, any process getting into > > > kernel mode can easily assume that the kernel mode stack is always free > > > whenever it gets into kernel mode. > > > > Maybe... However it would need at least one stack per cpu and making the > > kernel non preemptive is bad for system responsiveness. > > > > I think sleeping in the kernel will make using a common kernel stack > extremely difficult (if not theoretically impossible). > Suppose, while running some code in the kernel, process A goes to sleep > process B is scheduled. B will then use the stack for its own calls. If B > too goes to sleep then there is no way that A can be run without B unwinding > the stack first. Even if we decide to save the stack pointer separately for > each process then, A will at some point, overwrite B's frames since they > share the stack. > IMHO, the confusion lies in saying that 'only one process could be in > the kernel mode at a time'. Although, on a uniprocessor machine only one > process can be in the kernel mode at any given instant of time, more than > one processes can be executing in kernel mode quasi-parallelly. The point behind a non preemtive kernel is that it process A will *not* be interrupted, if it is executing kernel code. If it can be interrupted, the kernel is preemptive. However, you have system calls like read() which have to go to sleep, even in a non preemtive kernel. So you need at least some extra for these cases. This makes sharing stacks more complex. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
