[alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue
Tejun Heo
tj at kernel.org
Wed Aug 31 16:44:08 CEST 2016
Hello, Peter.
On Wed, Aug 31, 2016 at 02:56:50PM +0300, Peter Ujfalusi wrote:
> On 08/30/16 21:27, Bhaktipriya Shridhar wrote:
> > The workqueue "dac33_wq" queues a single work item &dac33->work and hence
> > doesn't require ordering. Also, it is not being used on a memory reclaim
> > path. Hence, it has been converted to use system_wq.
> >
> > The work item has been flushed in dac33_soc_remove to ensure that
> > there are no pending tasks while disconnecting the driver.
>
> The reason why dac33 had it's own wq is that it is absolutely time critical
> that the work is not going to be delayed by the scheduling needs with the
> system_wq. If the work execution is delayed, we could run out of time in FIFO
> mode, which can cause the chip to hang do to FIFO underrun.
In the current implementation of wq, which has been around for many
years now, there's no real timing advantage to using a dedicated
workqueue or rather system_wq doesn't get blocked by other work items
on it. They are all served by the same backend pools and dedicated
workqueues mostly serve as attribute, flush and mem-reclaim domains.
> Unfortunately I'm no longer able to test the dac33 as I don't have the HW any
> more.
>
> If you are 100% percent sure that this is not going to delay the work, then
> I'm OK with the change, but I have used the dedicated queue at the time,
> because the system_wq given unpredictable latencies.
What kind of time frame are we talking about? If it really needs high
priority, the right thing to do would be using a WQ_HIGHPRI workqueue.
Thanks.
--
tejun
More information about the Alsa-devel
mailing list