Re: [PATCH] local_irq_disable removal

[Sven-Thorsten Dietrich]

On Sat, 2005-06-11 at 18:00 +0300, Mika Penttilà wrote:
> Ingo Molnar wrote:
> 
> >i've done two more things in the latest patches:
> >
> >- decoupled the 'soft IRQ flag' from the hard IRQ flag. There's
> >  basically no need for the hard IRQ state to follow the soft IRQ state. 
> >  This makes the hard IRQ disable primitives a bit faster.
> >
> >- for raw spinlocks i've reintroduced raw_local_irq primitives again.
> >  This helped get rid of some grossness in sched.c, and the raw
> >  spinlocks disable preemption anyway. It's also safer to just assume
> >  that if a raw spinlock is used together with the IRQ flag that the
> >  real IRQ flag has to be disabled.
> >
> >these changes dont really impact scheduling/preemption behavior, they 
> >are cleanup/robustization changes.
> >
> >	Ingo
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@xxxxxxxxxxxxxxx
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >  
> >
> With the soft IRQ flag local_irq_disable() doesn't seem to protect 
> against soft interrupts (via SA_NODELAY interrupt-> invoke_softirq()). 
> Could this be a problem?

Only if you run SOFT IRQs as SA_NODELAY, which is going to KILL all your
preemption gains with the first arriving network packet.

And that is, if you don't get buried in "scheduling while atomic" printk
messages first.

SA_NODELAY is not generally allowed in PREEMPT_RT, except for code
designed to take advantage of the IRQ void that has been created. 

This code must follow a new set of rules, which people who design RT
apps are really happy to accet, they have to accept worse compromises
with the alternatives (subkernel or ANOTHER OS (ugh))

Sven


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/