Message-Id: <1259329832.3053.33.camel@palomino.walls.org>
Date:	Fri, 27 Nov 2009 08:50:32 -0500
From:	Andy Walls <awalls@...ix.net>
To:	Tejun Heo <tj@...nel.org>
Cc:	Peter Ujfalusi <peter.ujfalusi@...ia.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Takashi Iwai <tiwai@...e.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: 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:
http://lwn.net/Articles/2.6-kernel-api/
and an older one:
http://lwn.net/Articles/239633/

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.

Regards,
Andy


> Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists