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

    On Sat, 11 Jun 2005, Daniel Walker wrote:

    >
    >
    > On Sat, 11 Jun 2005, Ingo Molnar wrote:
    >
    > > - for raw spinlocks i've reintroduced raw_local_irq primitives again.
    > > This helped get rid of some grossness in sched.c, and the raw
    > > spinlocks disable preemption anyway. It's also safer to just assume
    > > that if a raw spinlock is used together with the IRQ flag that the
    > > real IRQ flag has to be disabled.
    >
    > I don't know about this one .. That grossness was there so people aren't
    > able to easily add new disable sections.
    >
    > Could we add a new raw_raw_spinlock_t that really disable interrupt , then
    > investigate each one . There are really only two that need it, runqueue
    > lock , and the irq descriptor lock . If you add it back for all raw types
    > you just add back more un-needed disable sections. The only way a raw lock
    > needs to disable interrupts is if it's possible to enter that region from
    > interrupt context .
    >
    >
    > Daniel
    >
    >

    We must assume the !PREEMPT_RT writer never uses raw. If he starts to do
    that RT will be broken no matter what.

    What is it you want to obtain anyway?
    As far as I understand it comes from the discussion about
    local_irq_disable() in random driver X made for !PREEMPT_RT can destroy
    RT because the author used local_irq_disable() around a large,
    non-deterministic section of the code.

    That only has one solution:
    Disallow local_irq_disable() when PREEMPT_RT is on and make some easy
    alternatives. Many of them could be turned into raw_local_irq_disable(),
    others into regular locks.

    If you want extremely low interrupt latencies I say it is better to use a
    sub-kernel - which might be a very, very simple interrupt-dispatcher.

    I think the PREEMPT_RT should go for deterministic task-latencies. Very
    low interrupt, special perpose latencies is a whole other issue which I
    think should be posponed - and at least should be made obtional.

    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/

    \
     
     \ /
      Last update: 2005-06-11 18:50    [W:0.037 / U:94.936 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site