linux-kernel - Re: [PATCH] workqueue: introduce queue_work_cpumask to queue work onto a given cpumask

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]

Message-ID: <ZIdbyOBdU6zAGxVw@slm.duckdns.org>
Date:   Mon, 12 Jun 2023 07:54:16 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Yuanhan Zhang <zyhtheonly@...il.com>
Cc:     jiangshanlai@...il.com, linux-kernel@...r.kernel.org,
        pmladek@...e.com, zyhtheonly@...h.net, zwp10758@...il.com,
        tiozhang@...iglobal.com, fuyuanli@...iglobal.com
Subject: Re: [PATCH] workqueue: introduce queue_work_cpumask to queue work
 onto a given cpumask

Hello,

On Fri, Jun 09, 2023 at 02:28:19PM +0800, Yuanhan Zhang wrote:
> // I resend this to put it into the same thread, sorry for the confusion.

This got resent quite a few times and I don't know which one to reply to.
Just picking the one which seems like the latest.

> > Can you elaborate the intended use cases?
> 
> Thanks for your reply! Please let me use myself as an example to explain this.
> 
> In my scenario, I have 7 cpus on my machine (actually it is uma, so
> queue_work_node
> or using UNBOUND do not works for me), and for some unlucky reasons
> there are always some irqs running on cpu 0 and cpu 6, since I'm using arm64
> with irqs tuning into FIFO threads, those threaded irqs are always running on
> cpu 0 and 6 too (for affinity). And this would not be fixed easily in
> short terms :(
> 
> So in order to help async init for better boot times for my devices,
> I'd like to prevent
> works from running on cpu 0 and 6. With queue_work_cpumask(), it would be simply
> done by:
> 
> ...
> cpumask_clear_cpu(0, cpumask);  // actually I use sysfs to parse my cpumask
> cpumask_clear_cpu(6, cpumask);
> queue_work_cpumask(cpumask, my_wq, &my_work->work);
> ...

But this would require explicit code customization on every call site which
doesn't seem ideal given that this is to work around something which is tied
to the specific hardware.

Wouldn't it be better to add a kernel parameter to further constrain
wq_unbound_cpumask? Right now, on boot, it's only determined by isolcpus but
it shouldn't be difficult to add a workqueue parameter to further constrain
it.

Thanks.

-- 
tejun