From: Tejun Heo <tj@kernel.org>
To: Xin Zhao <jackzxcui1989@163.com>
Cc: jiangshanlai@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] workqueue: Support RT workqueue
Date: Thu, 16 Oct 2025 05:32:18 -1000 [thread overview]
Message-ID: <aPEQAqGOWOzzZl4Y@slm.duckdns.org> (raw)
In-Reply-To: <20251016102345.2200815-1-jackzxcui1989@163.com>
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.
--
tejun
next prev parent reply other threads:[~2025-10-16 15:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 10:23 Xin Zhao
2025-10-16 15:32 ` Tejun Heo [this message]
2025-10-17 9:10 ` Xin Zhao
2025-10-17 15:15 ` Tejun Heo
2025-10-17 15:16 ` Tejun Heo
2025-10-17 6:19 ` kernel test robot
2025-10-17 6:26 ` Christoph Hellwig
2025-10-17 8:23 ` Xin Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aPEQAqGOWOzzZl4Y@slm.duckdns.org \
--to=tj@kernel.org \
--cc=jackzxcui1989@163.com \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®