linux-kernel - Re: [PATCH v1 2/2] serial: 8250_dma: add parameter to queue work on specific cpu

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: <20251021173933.1077124-1-jackzxcui1989@163.com>
Date: Wed, 22 Oct 2025 01:39:33 +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 06:40:04 -1000 Tejun Heo <tj@...nel.org> wrote:

> > True, which is something that the rt changes should have addressed.
> > This sounds like an overall rt issue, not a serial port issue.  Have you
> > asked about this on the rt mailing list?
> 
> Maybe it's mostly RT; however, because of the shared worker pool
> implementation, workqueue can introduce high tail latencies, especially
> depending on what mm is doing. When a work item is scheduled, there would
> usually be a worker thread that can service it right away; however, there's
> no guarantee and when it gets unlucky it may have to create a new kworker
> for the pool, which can easily add some msecs of delay. If the system is
> under even moderate memory pressure, that can shoot up considerably too.
> 
> I'm not convinced WQ_HIGHPRI is a good solution tho. It changes scheduling
> priority and it likely reduces the probabilty of having to create a new
> kworker as highpri pools are a lot less utilized. However, that can still
> happen. If consistent low latency is really important, it should use
> dedicated kthread workers with appropriate priority bump.

Thank you for your insights about high tail latencies. However, the spikes
I'm encountering in the project related to kworker still stem from RT
processes preempting kworker threads that are already executing. In our
project, I have already implemented my optimization approach by queuing
work to CPU0, since there aren't as many long-running real-time tasks on CPU0.
Moreover, some logic on CPU0 replies on the tty uart data, which provides a
degree of complementarity from the perspective of CPU resource usage. From
the experimental data results, the most significant optimization effect comes
from queuing work to this fixed CPU0, rather than using the WQ_HIGHPRI flag,
although WQ_HIGHPRI does provide some improvement.
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.
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
on whether there is any impact on performance. In other words, for developers
working on the tty driver in this context, it might be difficult to practically
accept changes to a large portion of the current work code in tty, making
implementation quite challenging.

--
Xin Zhao