Message-Id: <20251022135959.127893-1-jackzxcui1989@163.com>
Date: Wed, 22 Oct 2025 21:59:59 +0800
From: Xin Zhao <jackzxcui1989@....com>
To: tj@...nel.org
Cc: gregkh@...uxfoundation.org,
	hch@...radead.org,
	jackzxcui1989@....com,
	jirislaby@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH v1 2/2] serial: 8250_dma: add parameter to queue work on specific cpu

On Tue, 21 Oct 2025 08:50:16 -1000 Tejun Heo <tj@...nel.org> wrote:

> > I also agree that tasks requiring continuous real-time execution should be
> > handled by kthread workers. However, while the ideal situation is appealing,
> > the reality is challenging. A large amount of driver code in the system uses
> > the system's pwq and worker_pool management, as this API is very convenient.
> > Refactoring the code carries significant change risks, and even with a team
> > effort, it's hard to bear such risks.
> 
> kthread_work's API is really similar to workqueue to make it easy to switch
> between the two. We probably didn't go far enough tho and it may make sense
> to allow workqueue to always use dedicated fixed set of workers (e.g. by
> allowing a workqueue to create a private pool of workers) when configured
> from userspace so that this becomes a configuration problem which doesn't
> require code changes.

kthread_work's API is greate for system which do not care about throughput but
concern with real-time performance. It is suitable for scenarios where a single
work instance corresponds to a single workqueue. In situations where a
workqueue corresponds to multiple different works, using kthread_work does not
create threads as needed. To address this, we might consider adding a new
interface, perhaps called kthread_run_workqueue. Unlike kthread_run_worker,
this new interface would determine whether to create a new thread based on the
pointer to the work instance passed in, ensuring that each work uniquely
corresponds to a thread. This approach has several advantages: it allows for
seamless switching between the existing workqueue's queue work logic and
kthread_work, and it can help avoid missing any work associated with a particular
workqueue, especially in large corebase containing multiple layers.
If the kthread_work API does not provide the functionality to create different
threads for different works, then I think a private worker pool is meaningful.
However, it may still lead to potential blocking for subsequent works if multiple
different works arrive concurrently while there is only one active kworker thread.

> > Adding flags like WQ_HIGHPRI or even introducing WQ_RT from a functional
> > development perspective doesn't pose too much concern; we just need to focus
> 
> WQ_RT really doesn't make sense given that you can't even tell whether any
> given work item would have a worker ready for it. What does RT priority do
> when you need to go and create a new kworker?

Indeed, WQ_RT cannot address the issue of multiple different works arriving
concurrently in the same worker pool leading to delays, as just mentioned.
The creation of new threads on demand in a work queue, from the perspective
of the current code implementation, is inherently non-real-time.
It seems that only the kthread_work mechanism can ensure that work tasks are
executed in real-time. I will use it to solve another GPU-related kworker
issue that I encounter in our system.

> Note that workqueue property changes don't need to be hard coded. If you
> make the code use its own workqueue and set WQ_SYSFS, you can change its
> properties from userspace through sysfs interface.

Regarding the current kworker preemption issue with 8250_dma, based on our
current measurements, using the kworker API is sufficient. Additionally, if
we switch to kthread_work, the tty driver layer would require significant
modifications. Therefore, I will adopt the WQ_SYSFS approach you mentioned,
as it is quite convenient for dynamic control from user space.

--
Xin Zhao

Powered by blists - more mailing lists