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] [day] [month] [year] [list]

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

On Wed, 22 Oct 2025 18:59:05 +0200 Greg KH <gregkh@...uxfoundation.org> wrote:

> > > This should come from a hardware definition somewhere in your DT, not as
> > > a user-selectable option.  And again, why not just tie it to the cpu
> > > where the irq came from automatically?
> > 
> > I don't think binding the work task to the CPU that handles the interrupt is feasible,
> > because, in practice, this hardware interrupt is evenly distributed across all cores
> > in our system.
> 
> I suggest fixing that, that's ripe for lots of latency as cores hit
> cache misses and the like.  Learn from the networking people, you want
> the cpu that handled the irq to handle the data processing too.  They
> learned that years ago.
> 
> > Moreover, from the ftrace data we captured, the IRQ handler thread that
> > wakes up the kworker threads in RT-Linux is also distributed across various CPUs by
> > default.
> 
> Again, don't do that, bind things to cpus that previously handled the
> data if at all possible to avoid these latencies.  That's what you are
> trying to do here anyway, so you kind of have proof of that being a
> viable solution :)

Thank you for your suggestion. I will perform the relevant interrupt affinity binding on
our system.

--
Xin Zhao