linux-kernel - Re: linux-next: workqueues tree build failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1259239225.3062.16.camel@palomino.walls.org>
Date:	Thu, 26 Nov 2009 07:40:25 -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 Thu, 2009-11-26 at 18:12 +0900, Tejun Heo wrote:
> Hello,
> 
> 11/26/2009 05:16 PM, Peter Ujfalusi wrote:
> >> Takashi, RT workqueue is going away.  Do you really need it?
> > 
> > What can be used instead of RT workqueue?
> > The tlv320dac33 needs RT workqueue because I need to send the I2C
> > command with minimum delay to the codec. If this can not be done
> > (the workqueue is delayed), and the codec does not receive the
> > command in time, it will literally die.  What are the options to
> > replace the RT workqueue?
> 
> The problem with RT workqueue is that RT and queue don't really mix
> well.  To act in real time, it requires all the resource pre-allocated
> and dedicated to it making queueing or pooling meaningless.  The
> original workqueue code created dedicated pool of threads for each
> workqueue so it could be used for RT but new implementation uses
> shared worker pool, so it can't be used as an interface to dedicated
> threads.
> 
> I haven't read the code but,
> 
> * If you need to respond fast, wouldn't you be doing that from IRQ
>   handler or softirq?  Do you need task context?

Hi Tejun,

I'm not sure doing things like I2C transactions in the in the top half
of the IRQ handler is generally viable.  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.

Workhandlers for deferring work are a nice way to avoid such bad system
level interactions.

Regards,
Andy


> * Or is it that it's not triggered by IRQ but once the transfer
>   started it can't be interrupted?  But in this case preempt_disable()
>   or local_irq_disable() should suffice.
> 
> 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/