On Sun, Jan 17, 2010 at 10:34 PM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote: > Why is preemption disabled before a lock is acquired in _spin_lock function? > theoretically, if your interrupt handling codes is sharing some data with your kernel codes, then assuming u have one CPU, it is possible they will collide on the same variable. so disabling preemption is important, by disabling the interrupt. but, nowadays, the goal of preemption disabling is more than that. it has been discovered that preemption overheads is actually quite high, and by disabling it, effective performance throughput is higher, though the system may not react as fast as u like in every tasks - which is the basic requirement of realtime kernel. For eg, look under here: http://rt.wiki.kernel.org/index.php/Publications for a paper by Paul Kenney - OLS 2008 (real-fast vs realtime).....where he emphasized that realtime kernel (where kernel is instrumented with lots of preemption points) is always slower than those without. and perhaps one more relevant reference: http://kerneltrap.org/node/2702 and as for spinlock.....that is to protect from multiple CPU scenario..... > As the critical region of code which is to be protected by the spin > lock executes only after the lock is acquired, why is disabling of > preemption required before the lock is acquired? > > Wouldn't it better if the kernel code that does the spinning before > the lock is acquired is itself preempted so that someone else can run > in the meanwhile? > > Thanks, > -Joel > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
