Re: [PATCH] local_irq_disable removal

[Esben Nielsen]

On Fri, 10 Jun 2005, Daniel Walker wrote:

> On Sat, 2005-06-11 at 01:37 +0200, Esben Nielsen wrote:
> [...]
> > As far as I can see the only solution is to replace them with a per-cpu
> > mutex. Such a mutex can be the rt_mutex for now, but someone may want to
> > make a more optimized per-cpu version where a raw_spin_lock isn't used.
> > That would make it nearly as cheap as cli()/sti() when there is no
> > congestion. One doesn't need PI for this region either as the RT
> > subsystems will not hit it anyway.
> 
> I don't like this solution mainly because it's so expensive. cli/sti may
> take a few cycles at most, what your suggesting may take 50 times that,
> which would similar in speed to put linux under adeos.. 

We are only talking about the local_irq_disable()/enable() in drivers, not
the core system, right? Therefore making it into a mutex will not be that
expensive overall.

> Plus take into
> account that the average interrupt disable section is very small .. I
> also think it's possible to extend my version to allow those section to
> be preemptible but keep the cost equally low.
> 

The more I think about it the more dangerous I think it is. What does
local_irq_disable() protect against? All local threads as well as
irq-handlers. If these sections keeped mutual exclusive but preemtible we
will not have protected against a irq-handler.

I will start to play around with the following:
1) Make local_irq_disable() stop compiling to see how many we are really
talking about.
2) Make local_cpu_lock, which on PREEMPT_RT is a rt_mutex and on
!PREEMPT_RT turns into local_irq_disable()/enable() pairs. To introduce
this will demand some code-analyzing for each case but I am afraid there
is no general one-size solution to all the places.

> Daniel
> 
> 

Esben


-
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/