Re: [PATCH] local_irq_disable removal

[Sven-Thorsten Dietrich <sdietrich@mvista.com>]

On Sun, 2005-06-12 at 13:15 +0200, Esben Nielsen wrote:
> On Sun, 12 Jun 2005, Ingo Molnar wrote:
> I am surprised that is should actually be faster, but I give in to the
> experts. I will see if I can find time to perform a test or I should spend
> it on something else.
> 
> That said, this long discussion have not been a complete waste of time: I
> think this thread have learned us that we do have different goals and
> clarifies stuff.
> 
> I am not happy about the soft-irq thing. Mostly due to naming.
> local_irq_disable() is really just preempt_disable() with some extra stuff
> to make it backward combatible. 
> I still believe local_irq_disable() (also in the soft version) should be
> completely forbidden when PREEMPT_RT is set. All places using it should be
> replaced with a mutex or a ???_local_irq_disable() to mark that the code
> have been reviewed for PREEMPT_RT. With your argument above 
> ???_local_irq_disable() should really be preempt_disable() as that is
> faster.
> 

Hi Esben,

I just wondered if you are talking about the scenario where an interrupt
is executing on one processor, and gets preempted. Then some code runs
on the same CPU, which does local_irq_disable (now preempt_disable), to
keep that IRQ from running, but the IRQ thread is already started?

In the community kernel, this could never happen, because IRQs can't be
preempted. But in RT, its possible an IRQ could be preempted, and under
some circumstance, this sequence could occur.

Is that is what you are talking about? If not, it might be over my head,
and I am sorry. If so, I think that scenario is covered under SMP.

Sven


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