Re: [PATCH] local_irq_disable removal

[Esben Nielsen <simlo@phys.au.dk>]

On Mon, 13 Jun 2005, Sven-Thorsten Dietrich wrote:

> 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
> 
No, Sven it is not. I am not so worried about that scenario.
I am worried about some coder somewhere still using local_irq_disable() -
there is a lot of code out there doing that. We have not confirmed that
all of it really locks small enough regions to preserver RT preemption.
I for one is doubtfull about the cmos_lock thingy. (Sorry, can't connect
to my machine at home to check where it is, right now.) A very weird setup
with a kind of homebrewn spinlock.
All these cases needs to be reviewed to see if it is valid to use a
global lock type like local_irq_disable() or a local mutex must be used.
The former is only "allowed" if the time being within the locked is
deterministicly only in the order of the time for scheduling.
I wanted to add a extra name to the namespace stating "this usage of
local_irq_disable() have been reviwed wrt. RT_PREEMPT".

Esben

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