linux-kernel - Re: [PATCH] wifi: wfx: add WQ_PERCPU to alloc

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] [day] [month] [year] [list]

Message-ID: <20251113172159.a-yjqge1@linutronix.de>
Date: Thu, 13 Nov 2025 18:21:59 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Jérôme Pouiller <jerome.pouiller@...abs.com>
Cc: linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
	Marco Crivellari <marco.crivellari@...e.com>,
	Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
	Frederic Weisbecker <frederic@...nel.org>,
	Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] wifi: wfx: add WQ_PERCPU to alloc_workqueue users

On 2025-11-13 17:57:40 [+0100], Jérôme Pouiller wrote:
> > -       wdev->bh_wq = alloc_workqueue("wfx_bh_wq", WQ_HIGHPRI, 0);
> > +       wdev->bh_wq = alloc_workqueue("wfx_bh_wq", WQ_HIGHPRI | WQ_PERCPU, 0);
…
> BTW, this workqueue has changed multiple times. I though it was already
> unbound (and I believe it should).

It is not unbound. It can be enqueued on any CPU but the work item/
worker not migrate to another CPU should there be resources available)
compared to the CPU performing the enqueue.

> I also think the HIGHPRI is not required (the device perform better
> with HIGHPRI, but this is only because we steal the CPU of the other
> tasks).

HIGHPRI sets the nice level as per nice(2).
I did look a bit and one of the users is a threaded interrupt as of
wfx_spi_irq_handler(). This is already a thread with SCHED_FIFO 50.
You can sleep here or do anything else that you could in a workqueue.
This thread will be preferred to other threads in the system which run
usually at SCHED_OTHER including the worker.

Not sure if the requirement for the additional offload is to be able to
serve another interrupt before the worker completes.

Sebastian