linux-kernel - Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread

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]

Date:   Wed, 31 Aug 2016 10:44:08 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     Bhaktipriya Shridhar <bhaktipriya96@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated
 create_singlethread_workqueue

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