[lkml]   [2005]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] local_irq_disable removal

On Sat, 11 Jun 2005, Sven-Thorsten Dietrich wrote:

> On Sat, 2005-06-11 at 21:34 +0200, Esben Nielsen wrote:
> > On Sat, 11 Jun 2005, Ingo Molnar wrote:
> >
> > >
> > > * Daniel Walker <> wrote:
> > >
> > > > > The current soft-irq states only gives us better hard-irq latency but
> > > > > nothing else. I think the overhead runtime and the complication of the
> > > > > code is way too big for gaining only that.
> > > >
> > > > Interrupt response is massive, check the adeos vs. RT numbers . They
> > > > did one test which was just interrupt latency.
> > >
> > > the jury is still out on the accuracy of those numbers. The test had
> > > RT_DEADLOCK_DETECT (and other -RT debugging features) turned on, which
> > > mostly work with interrupts disabled. The other question is how were
> > > interrupt response times measured.
> > >
> > You would accept a patch where I made this stuff optional?
> >
> Daniel's original patch MADE it optional. Its just that the code is
> apparently more complex looking that way, so its cleaner to do what Ingo
> did.
> > I have another problem:
> > I can't hide that my aim is to make task-latencies deterministic.
> Then this will help you.
No because it correctly leaves irqs on but not preemption on.

> > The worry is local_irq_disable() (and preempt_disable()). I can undefine
> > it and therefore find where it is used. I can then look at the code, make
> > it into raw_local_irq_disable() or try to make a lock.
> > In many cases the raw-irq disable is the best and simplest when I am only
> > worried about task-latencies. But now Daniel and Sven wants to use the
> > distingtion between raw_local_irq_disable() and local_irq_disable() to
> > make irqs fast.
> We aim to make IRQ latencies deterministic. This affects preemption
> latency in a positive way.
No. If you leave preemption off but irqs on, which is what is done here,
you get good, deterministic IRQ latencies but nothing for task-latencies -
actually slightly (unmeassureable I agree) worse due to the extra step
you have to go from the physical interrupt to the task-switch is

> Anywhere in the kernel that IRQs are disabled, preemption is impossible.
> (you can't interrupt the CPU when irqs are disabled)
For me it is the _same_ thing. Equally bad. If preemption is off I don't
care if irqs are off.

> But you said you are worried about overhead. You have to incur overhead
> to make task response deterministic.
> Are you sure you are not just trying to make it FAST?
Certainly not. I was pressing for priority inheritance forinstance. That
thing does certainly not make it fast, but it makes use of locks

> But then - even if you do, this is still in your interest.
> Let's wait for some numbers.
> > We do have a clash of notations. Any idea what to do? I mentioned
> > local_
> The following two are the same. The former is an earlier implementation,
> and has been superseded by the latter. The former is NLA.
> > raw_local_
> > hard_local_
My idea was to split them:
local_ are disallowed in PREEMPT_RT to catch code been made !PREEMPT_RT
suddenly destroying RT.
raw_local_ is used all over in PREEMPT_RT core code.
hard_local_ is the same as raw_local unless you configure for low IRQ
latencies (the original patch). Then it marks the soft-irq state.

Do you follow my idea:
I can persue low task latencies. You can persue low irq latencies and we
don't clash due to conflicting naming convensions.


> Sven

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-06-11 22:31    [W:0.172 / U:0.152 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site