linux-kernel - Re: [PATCH 2/2] nvme-pci: allow unmanaged interrupts

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: <ce50c633-598e-4252-88fd-109954808b2b@gmail.com>
Date: Mon, 13 May 2024 14:33:14 +0200
From: Benjamin Meier <benjamin.meier70@...il.com>
To: ming.lei@...hat.com
Cc: benjamin.meier70@...il.com, hch@....de, kbusch@...nel.org,
 kbusch@...a.com, linux-kernel@...r.kernel.org,
 linux-nvme@...ts.infradead.org, tglx@...utronix.de
Subject: Re: [PATCH 2/2] nvme-pci: allow unmanaged interrupts

 > 'isolcpus=managed_irq' enablement patches are small, and shouldn't be 
very
 > hard to backport.

I have big respect of kernel code and probably for non-kernel devs it's 
not so easy:)

But yeah, we'll look into this.

 > > > > be tricky to assign all interrupts to those without a
 > > performance-penalty.
 > > > >
 > > > > Given these requirements, manually specifying interrupt/core 
assignments
 > > > > would offer greater flexibility and control over system 
performance.
 > > > > Moreover, the proposed code changes appear minimal and have no
 > > > > impact on existing functionalities.
 > > >
 > > > Looks your main concern is performance, but as Keith mentioned, the
 > > proposed
 > > > change may degrade nvme perf too:
 > > >
 > > > 
https://lore.kernel.org/linux-nvme/Zj6745UDnwX1BteO@kbusch-mbp.dhcp.thefacebook.com/
 > >
 > > Yes, but for NVMe it's not that critical. The most important point 
for us is
 > > to keep them away from our "high-priority" cores. We still wanted 
to have
 > > control
 > > where we run those interrupts, but also because we just did not 
know the
 > > "managed_irq"
 > > option.
 >
 > OK, thanks for share the input!
 >
 > Now from upstream viewpoint, 'isolcpus=managed_irq' should work for 
your case,
 > and seems not necessary to support nvme unmanaged irq for this 
requirement
 > at least.

Yes, probably that will do it. Personally, I still think it's a nice 
thing if it's
possible to assign interrupts to specific cores, but practically the 
advantages are
likely not that big compared to 'isolcpus=managed_irq'.

Thanks for all the explanations