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

Message-Id: <20241213123643.1898-1-hdanton@sina.com>
Date: Fri, 13 Dec 2024 20:36:43 +0800
From: Hillf Danton <hdanton@...a.com>
To: Brian Vazquez <brianvv@...gle.com>,
	Marco Leogrande <leogrande@...gle.com>
Cc: 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 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.

> 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.