lkml.org 
[lkml]   [2005]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] local_irq_disable removal
    From
    Date
    On Sat, 2005-06-11 at 19:16 +0200, Esben Nielsen wrote:
    > On Sat, 11 Jun 2005, Sven-Thorsten Dietrich wrote:
    >
    > > On Sat, 2005-06-11 at 16:32 +0200, Esben Nielsen wrote:
    > >
    > > > > > The more I think about it the more dangerous I think it is. What does
    > > > > > local_irq_disable() protect against? All local threads as well as
    > > > > > irq-handlers. If these sections keeped mutual exclusive but preemtible
    > > > > > we will not have protected against a irq-handler.
    > > > >
    > > The more Dangerous you perieve it to be. Can you point to real damage?
    > > After all this is experimental code.
    > >
    > > > That is exactly my point: We can't make a per-cpu mutex to replace
    > > > local_irq_disable(). We have to make real lock for each subsystem now
    > > > relying on local_irq_disable(). A global lock will not work. We could have
    > > > a temporary lock all non-RT can share but that would be a hack similar to
    > > > BKL.
    > > >
    > >
    > > Why do we need any of this?
    >
    > If we want deterministic task-latencies without worrying about
    > proof-reading the code of every subsystem which might be using
    > local_irq_disable() in some non-deterministic way, we need to make another
    > locking mechanism.

    Why would you want to encourage oddball approaches to driver
    development?

    If a driver is causing problems this way, it should be looked at from a
    design perspective, because that sort of coding style usually causes
    problems with SMP as well.

    > >
    > > > 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.
    > >
    > >
    > > Real numbers please, not speculation! Science, not religion.
    > >
    > Well, isn't enough to see that the code contains more instructions and
    > looks somewhat more complicated?
    >

    It clarifies design aspects of the kernel, and identifies code that has
    different behavior assumptions associated with it, than other code that
    disables IRQs. Its a good thing to separate that out, because then you
    know what you are looking at, rather than having to assume it.


    -
    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 21:37    [W:2.456 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site