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
| ||
|
Message-ID: <aEinW8EpI2x6JrnO@slm.duckdns.org> Date: Tue, 10 Jun 2025 11:44:59 -1000 From: Tejun Heo <tj@...nel.org> To: Marco Crivellari <marco.crivellari@...e.com> Cc: Lai Jiangshan <jiangshanlai@...il.com>, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Michal Hocko <mhocko@...e.com> Subject: Re: [PATCH v2 2/4] Workqueue: add system_dfl_wq Hello, On Tue, Jun 10, 2025 at 10:56:13AM +0200, Marco Crivellari wrote: > >What is the reason for removing system_unbound_wq? I believe system_unbound_wq > >is a perfectly appropriate and descriptive name for its callers. I’m not opposed > >to system_dfl_wq as long as it will be an alias for system_unbound_wq (or even > >system_percpu_wq, if that can be configured at boot time by sysadim). > > The rename to system_dfl_wq is mostly to make sure this is the default wq choice > when per-cpu is not strictly needed. > It has been proposed here, anyhow: > > https://lore.kernel.org/all/Z79E_gbWm9j9bkfR@slm.duckdns.org/ I think we ultimately want to converge on one thing and I think it does make sense to make one behavior default over the other. ie. If we make percpu the flavor that requires explicit designation, unbound by default becomes the default. ie. I don't want a situation where there are system_percpu_wq and system_unbound_wq as it's not clear which one is preferred, and if we add system_dfl_wq to clarify the situation, at least in the long term, having another alias for it makes things unnecessarily confusing. So, if we're flipping the default, I'd rather remove the unbound name from the interface. We can keep using unbound inside workqueue implementation of course. Thanks. -- tejun
Powered by blists - more mailing lists