[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.023 / U:3.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site