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: <20251017091041.3026848-1-jackzxcui1989@163.com>
Date: Fri, 17 Oct 2025 17:10:41 +0800
From: Xin Zhao <jackzxcui1989@....com>
To: tj@...nel.org
Cc: jackzxcui1989@....com,
	jiangshanlai@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: Support RT workqueue

On Thu, 16 Oct 2025 05:32:18 -1000 Tejun Heo <tj@...nel.org> wrote:
> Hello,
> 
> On Thu, Oct 16, 2025 at 06:23:45PM +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 kworker threads are shared globally based on the attributes of the
> > workqueue (wq) and the parameters of queue_work_on. This means that
> > regardless of whether you create a new wq or use an existing one, the
> > kworker thread that processes the work does not exclusively run any
> > specific work or work from a specific wq. While this design saves
> > resources, it makes it difficult to ensure the real-time execution of
> > work by modifying the priority of the kworker thread associated with a
> > specific work in hard real-time scenarios. Additionally, if I manually
> > set the real-time priority of the kworker while executing the work task
> > and then adjust it back upon completion, the next time queue_work_on is
> > called, the priority of the kworker thread will have reverted, making it
> > impossible to ensure timely execution of these lower-priority threads.
> > Moreover, frequent priority adjustments can incur additional overhead.
> > Perhaps we could implement all logic related to hard real-time tasks
> > using kernel threads, but I believe this workload is unnecessary. The
> > existing workqueue mechanism in the system is well-structured and can
> > guarantee that work executes in an orderly manner in concurrent scenarios
> > by adjusting the max_active and WQ_ORDERED attributes. We only need to
> > introduce a WQ_RT flag and add a small amount of code to meet the
> > requirements of hard real-time workqueues.
> 
> For things that may need RT, please use kthread_work.
> 
> Thanks.

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.

--
Xin Zhao