From: Tejun Heo <tj@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Takashi Iwai <tiwai@suse.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: linux-next: workqueues tree build failure
Date: Thu, 26 Nov 2009 18:12:26 +0900 [thread overview]
Message-ID: <4B0E467A.8080201@kernel.org> (raw)
In-Reply-To: <200911261016.58810.peter.ujfalusi@nokia.com>
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.
Thanks.
--
tejun
next prev parent reply other threads:[~2009-11-26 9:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-26 8:00 linux-next: workqueues tree build failure Stephen Rothwell
2009-11-26 8:04 ` Tejun Heo
2009-11-26 8:16 ` Peter Ujfalusi
2009-11-26 9:12 ` Tejun Heo [this message]
2009-11-26 9:24 ` Takashi Iwai
2009-11-26 9:31 ` Peter Ujfalusi
2009-11-26 10:18 ` Mark Brown
2009-11-26 11:44 ` Peter Ujfalusi
2009-11-26 12:49 ` Andy Walls
2009-11-26 13:23 ` Peter Ujfalusi
2009-11-26 12:40 ` Andy Walls
2009-11-26 12:56 ` Mark Brown
2009-11-27 2:02 ` Tejun Heo
2009-11-27 8:37 ` Takashi Iwai
2009-11-27 8:42 ` Tejun Heo
2009-11-27 10:09 ` Peter Ujfalusi
2009-11-27 11:38 ` Mark Brown
2009-11-27 13:50 ` Andy Walls
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B0E467A.8080201@kernel.org \
--to=tj@kernel.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=peter.ujfalusi@nokia.com \
--cc=sfr@canb.auug.org.au \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).