linux-kernel - Re: [PATCH] workqueue: Support RT workqueue

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: <aPJdrqSiuijOcaPE@slm.duckdns.org>
Date: Fri, 17 Oct 2025 05:15:58 -1000
From: Tejun Heo <tj@...nel.org>
To: Xin Zhao <jackzxcui1989@....com>
Cc: jiangshanlai@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: Support RT workqueue

Hello, Xin.

On Fri, Oct 17, 2025 at 05:10:41PM +0800, Xin Zhao wrote:
> Thank you for your suggestion. We can indeed replace some simple work usage
> scenarios with kthread_work. However, it is not a panacea, especially in
> cases where work processing requires concurrency.
> If we cannot use the RT workqueue implementation, we need to create another
> kthread to improve concurrency performance? In addition, we may need to
> incorporate logic to split works that are originally of the same type?
> This splitting modification can be quite time-consuming and is likely to
> encounter various strange errors during the split.
> Given that the workqueue mechanism is so excellent and effectively matches
> the needs for concurrent and ordered work while also managing work thread
> resources efficiently, perhaps we should consider adding the RT workqueue
> feature to the kernel. After all, the changes are too simple to carry any
> minimal risk, yet the benefits could be substantial in handling concurrent
> demands and preventing thread resource wastage.
> If we do not pursue this, continue relying on kthread_work to handle RT-prio
> work concurrency, it would be equivalent to re-implementing the logic of
> pwq and worker_pool.

There are a couple reasons why I don't think we don't want to go this way:

- Maybe RT is enough for your specific use case but others may want to use
  e.g. deadline, pinning to specific CPUs, persistent kthread-tied
  accounting and prioritization (note that kworkers carries arbitrary
  scheduling history across work item boundaries).

- Running anything RT presents a signficant cost to the system overall.
  There's significant loss in terms of the scheduler's ability to manage the
  system. Once you have too many things running in RT, you just don't have a
  working scheduler on the system. So, I think it makes sense to keep the
  decision to allow / use RT a clearly deliberate choice, something which
  has to be a lot more intentional than picking a different workqueue.

This will be a pretty hard no from me. Of course, I can be wrong and you can
argue your case, but it'd probably be most effective if the arguments are
based on concrete and specific use cases.

Thanks.

-- 
tejun