public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Xin Zhao <jackzxcui1989@163.com>,
	hch@infradead.org, jirislaby@kernel.org,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH v1 2/2] serial: 8250_dma: add parameter to queue work on specific cpu
Date: Tue, 21 Oct 2025 06:40:04 -1000	[thread overview]
Message-ID: <aPe3ZBCcyc5XR7TO@slm.duckdns.org> (raw)
In-Reply-To: <2025102107-player-baggie-37fc@gregkh>

Hello,

On Tue, Oct 21, 2025 at 06:26:53PM +0200, Greg KH 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.

Thanks.

-- 
tejun

  reply	other threads:[~2025-10-21 16:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-21  8:39 [PATCH v1 2/2] serial: 8250_dma: add parameter to queue work on specific cpu Xin Zhao
2025-10-21 11:28 ` Greg KH
2025-10-21 13:05   ` Xin Zhao
2025-10-21 16:26     ` Greg KH
2025-10-21 16:40       ` Tejun Heo [this message]
2025-10-21 17:39         ` Xin Zhao
2025-10-21 18:50           ` Tejun Heo
2025-10-22 13:59             ` Xin Zhao
2025-10-22 14:47       ` Xin Zhao
2025-10-22 16:37         ` Tejun Heo
2025-10-22 17:15           ` Xin Zhao
2025-10-22 16:59         ` Greg KH
2025-10-22 17:20           ` 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=aPe3ZBCcyc5XR7TO@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jackzxcui1989@163.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@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