[lkml]   [2009]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: linux-next: workqueues tree build failure
    On Fri, 2009-11-27 at 11:02 +0900, Tejun Heo wrote:
    > Hello,
    > 11/26/2009 09:40 PM, Andy Walls wrote:
    > >> * If you need to respond fast, wouldn't you be doing that from IRQ
    > >> handler or softirq? Do you need task context?
    > >
    > > I'm not sure doing things like I2C transactions in the in the top half
    > > of the IRQ handler is generally viable.

    I'll back off on this statement a little as Mark Brown pointed out. Two
    16 bit exchanges on a 100 kHz I2C bus is, as a lower bound, 32/100000 =
    320 microseconds (ignoring stop and start bits, turn-around times, I2C
    master register access times, etc.). 320 usec isn't bad.

    But in general having a slow top half can have bad effects on other
    drivers sharing an IRQ line.

    > On shared IRQ lines, wouldn't
    > > this hold off the interrupt for another device for too long?
    > >
    > > For example, I already ran across the case of an error path in the ahci
    > > disk controller driver interrupt handler holding off interrupts from the
    > > cx18 driver longer than the CX23418 firmware would tolerate on a shared
    > > interrupt line.
    > Sounds like it should be using bottom half tasklet not workqueue.
    > Tasklet is exactly designed to handle situations like this. Is there
    > any reason tasklet can't be used?

    Well if we're talking about the cx18 driver:

    1. I recall reading a while ago that tasklets were on the way out.
    Here's a recent reference:
    and an older one:

    2. CX23418 IRQs that need deferred work can come in in very close
    succession. This is due to *one* mailbox of information from firmware
    to the cx18 driver and buffer notifications for multiple streams coming
    in on that mailbox and the firmware doesn't have a long timeout waiting
    for the mailbox to be handled by the cx18 driver. I needed to make sure
    sequential events get queued up properly and none of them dropped.
    Queueing up multiple defered work items with a tasklet seemed
    problematic compared to a workqueue.

    (3. Once upon a time, the cx18 buffer queues where protected by mutexes,
    which can sleep. Sleeping wasn't allowed in a tasklet but was in
    workhandlers. Those queue locks are now spinlocks though.)

    But in the case I mentioned above for the cx18 and ahci drivers with
    devices that share an interrupt - tasklet vs. workqueue doesn't matter.

    There is a variable, but often short, time interval from CX23418 raising
    the IRQn to provide notification of a completed buffer DMA, until the
    CX23418 gives up waiting for cx18 driver ack and begins to overwrite
    that notification with a new one.

    If the ahci driver is servicing an interrupt for the shared IRQn and
    leaving it masked for a very long time, like it does in an error
    handling path, it is the ahci driver's interrupt service routine that is
    consuming the cx18 driver's timeline, not the workqueue delays.

    The fix for that is a system level one: don't have a data acquisition
    type peripherial like a CX23418 based TV capture card, share an IRQ with
    some other peripherial whose linux driver might have a sometimes slow
    top-half. Unfortunately, a normal home end user doesn't know to do that
    until he asks for help.



    > Thanks.

     \ /
      Last update: 2009-11-27 14:55    [W:0.025 / U:20.756 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site