Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4

[Ingo Molnar <mingo@elte.hu>]

* john cooper <john.cooper@timesys.com> wrote:

> Ingo,
>    In reading your -U3 patch the test below (#156)
> wasn't clear to me.   It would seem in the case of
> softirq_preemption, __do_softirq() should be called
> to kick ksoftirqd, otherwise ___do_softirq() would
> be called to exec softirqs in the immediate context.

the dependencies here are a bit complex due to the
various compile-time and runtime flags, and various
architecture call-ins to softirq.c.

> kernel/softirq.c:
> 
>  153   asmlinkage void _do_softirq(void)
>  154   {
>  155           local_irq_disable();
>  156           if (!softirq_preemption)
>  157                   __do_softirq();
>  158           else
>  159                   ___do_softirq();
>  160           local_irq_enable();
>  161   }

___do_softirq() is the 'lowest level' softirq function, it
directly executes the handlers.

__do_softirq() disables bhs and calls ___do_softirq() - this
is the 'direct' softirq execution model, this function is
called by hardirq contexts and by softirqd. [btw., irqd calls
this function too which is a bit pointless.] In the indirect
execution model (SOFTIRQ_PREEMPT) this function does no softirq
execution, it only wakes up softirqd.

_do_softirq() is what is called by softirqd - dependent on the
execution model this function will either execute ___do_softirq()
[no additional locking or bh disabling] in the threaded case,
while in the direct case it will execute __do_softirq().

so the logic seems to be correct to me. (except for the minor
detail of irqd calling __do_softirq() which doesnt make much 
sense but which is harmless otherwise.)

with DEBUG_PREEMPT it is relatively safe to call ___do_softirq()
from softirqd (without doing the extra bh disabling), because
the two main rules of softirqs are still preserved:

 1) softirq execution doesnt reenter itself

 2) per-CPU assumptions safely detected

	Ingo