Re: [PATCH] local_irq_disable removal

[Daniel Walker <dwalker@mvista.com>]

On Sat, 11 Jun 2005, Esben Nielsen wrote:

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

No, core system . We're talking about everything, including
raw_spinlock_t.
 
> 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.

Which IRQ handlers are those ? There is only one interrupt context handler
that must be protected, if you enable PREEMPT_HARDIRQS .
 
> 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.

I did that in my release notes , my patch reduced the number of cli's in
my kernel to 30% of what was in PREEMPT_RT .

Daniel

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