Re: [PATCH] local_irq_disable removal

Esben Nielsen
2005-06-11T16:46:30Z

On Sat, 11 Jun 2005, Daniel Walker wrote:

>
>
> On Sat, 11 Jun 2005, Ingo Molnar wrote:
>
> > - 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.
>
> I don't know about this one .. That grossness was there so people aren't
> able to easily add new disable sections.
>
> Could we add a new raw_raw_spinlock_t that really disable interrupt , then
> investigate each one . There are really only two that need it, runqueue
> lock , and the irq descriptor lock . If you add it back for all raw types
> you just add back more un-needed disable sections. The only way a raw lock
> needs to disable interrupts is if it's possible to enter that region from
> interrupt context .
>
>
> Daniel
>
>

We must assume the !PREEMPT_RT writer never uses raw. If he starts to do
that RT will be broken no matter what.

What is it you want to obtain anyway?
As far as I understand it comes from the discussion about
local_irq_disable() in random driver X made for !PREEMPT_RT can destroy
RT because the author used local_irq_disable() around a large,
non-deterministic section of the code.

That only has one solution:
Disallow local_irq_disable() when PREEMPT_RT is on and make some easy
alternatives. Many of them could be turned into raw_local_irq_disable(),
others into regular locks.

If you want extremely low interrupt latencies I say it is better to use a
sub-kernel - which might be a very, very simple interrupt-dispatcher.

I think the PREEMPT_RT should go for deterministic task-latencies. Very
low interrupt, special perpose latencies is a whole other issue which I
think should be posponed - and at least should be made obtional.

Esben