From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760186AbZKZJY2 (ORCPT ); Thu, 26 Nov 2009 04:24:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760141AbZKZJY1 (ORCPT ); Thu, 26 Nov 2009 04:24:27 -0500 Received: from cantor.suse.de ([195.135.220.2]:53965 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760069AbZKZJYZ (ORCPT ); Thu, 26 Nov 2009 04:24:25 -0500 Date: Thu, 26 Nov 2009 10:24:30 +0100 Message-ID: From: Takashi Iwai To: Tejun Heo Cc: Peter Ujfalusi , Stephen Rothwell , "linux-next@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mark Brown Subject: Re: linux-next: workqueues tree build failure In-Reply-To: <4B0E467A.8080201@kernel.org> References: <20091126190050.3f9d7fef.sfr@canb.auug.org.au> <4B0E3677.6000603@kernel.org> <200911261016.58810.peter.ujfalusi@nokia.com> <4B0E467A.8080201@kernel.org> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Thu, 26 Nov 2009 18:12:26 +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? > > * 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. The relevant code uses the workqueue as a sort of BH, just triggers from the hard irq handler. If any, we may use a threaded handler or so... thanks, Takashi