question about preempt_disable()

question about preempt_disable()

[Chris Peterson]

I just bought Robert Love's new book "Linux Kernel Development". The book
has been very informative, but I have some unanswered questions about kernel
preemption.

>From what I understand, SMP-safe code is also preempt-safe. The preempt
count is the number of spinlocks held by the current kernel thread. If the
preempt code is greater zero, then the kernel thread cannot be preempted.

My question is: if the code is already SMP-safe and holding the necessary
spinlocks, why is the preempt count necessary? Why must preemption be
disabled and re-enabled as spinlocks are acquired and released? Is it just
an optimization for accessing per-cpu data? Or is it necessary to prevent
priority inversion of kernel threads, when a low priority thread holds
spinlock X and is preempted by a high priority thread that hogs the CPU,
forever spinning in spin_lock(&X)?


chris

Re: question about preempt_disable()

[Matthias Urlichs]

Hi, Chris Peterson wrote:

> My question is: if the code is already SMP-safe and holding the necessary
> spinlocks, why is the preempt count necessary? Why must preemption be
> disabled and re-enabled as spinlocks are acquired and released?

You need to prevent deadlocks. Imagine process A grabbing a spinlock, then
getting preempted. Process B now sits there and waits on the spinlock.
Forward progress may or may not happen when the scheduler preempts B and
restarts A, some indeterminate time later.

Scheduling when waiting for a spinlock doesn't make sense because usually
the spinlock is held for just a few cycles (that's why it's a spin lock
and not a semaphore / wait queue / whatever), and rescheduling would take
more time than just waiting.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
You will have many recoverable tape errors.

Re: question about preempt_disable()

[Rob Love]

On Sun, 2003-11-30 at 12:39, Matthias Urlichs wrote:

> You need to prevent deadlocks. Imagine process A grabbing a spinlock, then
> getting preempted. Process B now sits there and waits on the spinlock.
> Forward progress may or may not happen when the scheduler preempts B and
> restarts A, some indeterminate time later.

Further, on uniprocessor systems, we don't have deadlocks so it is the
preempt_disable() that actually ensures concurrency is prevented in the
critical region.

	Rob Love

Re: question about preempt_disable()

[Matthias Urlichs]

Hi,

Rob Love wrote:
> Further, on uniprocessor systems, we don't have deadlocks so it is the
> preempt_disable() that actually ensures concurrency is prevented in the
> critical region.
>
We don't have _spin_locks.

-- 
Matthias Urlichs    |    {M:U} IT Design @ m-u-it.de     |    smurf@debian.org
Disclaimer: The quote was selected randomly. Really. | http://smurf.debian.net
 - -
I don't care how poor and inefficient a country is; they like to run their
own business. I know men that would make my wife a better husband than I am;
but, darn it, I'm not going to give her to 'em.
					-- Will Rogers

Re: question about preempt_disable()

[George Anzinger]

Chris Peterson wrote:
> I just bought Robert Love's new book "Linux Kernel Development". The book
> has been very informative, but I have some unanswered questions about kernel
> preemption.
> 
>>From what I understand, SMP-safe code is also preempt-safe. The preempt
> count is the number of spinlocks held by the current kernel thread. If the
> preempt code is greater zero, then the kernel thread cannot be preempted.
> 
> My question is: if the code is already SMP-safe and holding the necessary
> spinlocks, why is the preempt count necessary? Why must preemption be
> disabled and re-enabled as spinlocks are acquired and released? Is it just
> an optimization for accessing per-cpu data? Or is it necessary to prevent
> priority inversion of kernel threads, when a low priority thread holds
> spinlock X and is preempted by a high priority thread that hogs the CPU,
> forever spinning in spin_lock(&X)?

There are a couple of things here.  First, the preempt count includes other 
reasons not to preempt.  One of these is used when working with per-cpu data and 
a cpu switch would NOT be good (a pointer would point to the wrong cpu's data). 
  Also, at one time, the bh-lock was also cause to bump the preempt count.  In 
2.6, I think that is no longer true, BUT, the bh-count is in the same word. 
This is important as we want to test just one thing at interrupt return time to 
see if it is ok to preempt.  (Well, we actually have to test the need_resched 
flag too...)  From the interrupt codes point of view, the fact that the current 
task holds one or more spin locks is ONLY visible via the preempt count.  Thus 
the count collects all these things in one, easy to check, place.  This allows 
us to keep the interrupt path as fast as possible.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml