linux-kernel - Re: [iwl-next PATCH v3 2/3] idpf: convert workqueues to unbound

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: <CAMzD94Tt0ooCjV2y3-5TFxaZ_sy6PJ6W9zVvmDcHi82A3r8rhQ@mail.gmail.com>
Date: Mon, 16 Dec 2024 11:35:29 -0500
From: Brian Vazquez <brianvv@...gle.com>
To: Hillf Danton <hdanton@...a.com>
Cc: Marco Leogrande <leogrande@...gle.com>, Eric Dumazet <edumazet@...gle.com>, 
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [iwl-next PATCH v3 2/3] idpf: convert workqueues to unbound

On Fri, Dec 13, 2024 at 7:51 AM Hillf Danton <hdanton@...a.com> wrote:
>
> On Thu, 12 Dec 2024 23:33:32 +0000 Brian Vazquez <brianvv@...gle.com>
> > When a workqueue is created with `WQ_UNBOUND`, its work items are
> > served by special worker-pools, whose host workers are not bound to
> > any specific CPU. In the default configuration (i.e. when
> > `queue_delayed_work` and friends do not specify which CPU to run the
> > work item on), `WQ_UNBOUND` allows the work item to be executed on any
> > CPU in the same node of the CPU it was enqueued on. While this
> > solution potentially sacrifices locality, it avoids contention with
> > other processes that might dominate the CPU time of the processor the
> > work item was scheduled on.
> >
> > This is not just a theoretical problem: in a particular scenario
>
> The cpu hog due to (the user space) misconfig exists regardless it is
> bound workqueue or not, in addition to the fact that linux kernel is
> never the blue pill to kill all pains, so extra support for unbound wq
> is needed.
>

I agree that misconfig could exist even with unbound wq. Still unbound wq
gives the process an opportunity to run if resources are available, if
not, it means
that system is under stress and users should take a deeper look anyway.

> > misconfigured process was hogging most of the time from CPU0, leaving
> > less than 0.5% of its CPU time to the kworker. The IDPF workqueues
> > that were using the kworker on CPU0 suffered large completion delays
> > as a result, causing performance degradation, timeouts and eventual
> > system crash.