linux-kernel - Re: [RFC PATCH 0/3] workqueue: Add configure to reduce work latency

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: <aTMavHuVyOUPA9p8@slm.duckdns.org>
Date: Fri, 5 Dec 2025 07:47:40 -1000
From: Tejun Heo <tj@...nel.org>
To: Xin Zhao <jackzxcui1989@....com>
Cc: jiangshanlai@...il.com, hch@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] workqueue: Add configure to reduce work latency

Hello,

On Fri, Dec 05, 2025 at 08:54:42PM +0800, Xin Zhao wrote:
> In a system with high real-time requirements, we have noticed that many
> high-priority tasks, such as kernel threads responsible for dispatching
> GPU tasks and receiving data sources, often experience latency spikes
> due to insufficient real-time execution of work.
> The existing sysfs can adjust nice value for unbound workqueues. Add new
> 'policy' node to support three common policies: SCHED_NORMAL, SCHED_FIFO,
> or SCHED_RR. The original 'nice' node is retained for compatibility, add
> new 'rtprio' node to adjust real-time priority when 'policy' is SCHED_FIFO
> or SCHED_RR. The value of 'rtprio' uses the same numerical meaning as user
> space tool chrt.
> Introduce variable 'nr_idle_extra', which allows user space to configure
> unbound workqueue through sysfs according to the real-time requirement.
> By default, workqueue created by system will set 'nr_idle_extra' to 0.
> When the policy of workqueue is set to SCHED_FIFO or SCHED_RR via sysfs,
> 'nr_idle_extra' will be set to WORKER_NR_RT_DEF(2) as default.
> Supporting the private configuration aims to deterministically ensure that
> tasks within one workqueue are not affected by tasks from other workqueues
> with the same attributes. If the user has high real-time requirements,
> they can increase the nr_idle_extra supported in the previous patch while
> also setting the workqueue 'private', allowing it to independently use
> kworker threads, thus ensuring scheduling-related work delays never occur.

I don't think I'm applying this:

- The rationale is too vague. What are you exactly running and observing?
  How does this improve the situation?

- If wq supports private pools, then I don't think it makes sense to add wq
  interface to change their attributes. Once turned private, the worker
  threads are fixed and userspace can set whatever attributes they want to
  set, no?

Thanks.

-- 
tejun