Re: preemption when running in the kernel

[Frank Cusack <fcusack@fcusack.com>]

On Sat, Nov 08, 2003 at 07:23:05PM -0500, Robert Love wrote:
> On Sat, 2003-11-08 at 08:01, Ingo Oeser wrote:
> 
> > While having preemption disabled or while actually holding a spinlock,
> > preemption is disabled.
> > 
> > Disabling preemption is modifying a count, which must reach 0 again to
> > have preemption enabled and trigger an reschedule, if needed.
> > 
> > Think of it roughly as a "counter of reasons to not preempt". If there
> > are no reasons anymore, then we preempt.
> 
> Hi, Ingo.
> 
> This is an accurate description of 2.6, but Frank said for 2.4.
> 
> So, Frank, this is correct for 2.6 or 2.4 with the preempt-kernel patch,
> but not a stock 2.4 kernel.  A stock 2.4 kernel will never preempt a
> task running inside the kernel.

Thank you for the clarification.

That leads me to 2 followup questions.

If a task in the kernel is preempted, is a membar issued?  (I believe
so -- running another task means that the scheduler must have run,
which will grab and release various locks thus giving us the membars.)

When the preempted task resumes, is it guaranteed to run on the same CPU?
(I wouldn't expect so, unless the task was specifically told to do that
via hard affinity.  But maybe a task preempted in the kernel is different
then a task preempted in userland.)

/fc