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

    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/

    \
     
     \ /
      Last update: 2005-06-13 09:59    [W:0.035 / U:208.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site