linux-kernel - Re: [RFC PATCH v2 1/1] scsi: mpi3mr: Introduce smp_affinity

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

Message-ID: <1xjYfSjJndOlG0Uro2jPuAmIrfqi5AVbfpFeWh7RfLfzqqH9u8ePoqgaP32ElXrGyOB47UvesV_Y2ypmM3cZtWit2EPnV3aj6i9w_DMo1eI=@ashe.io>
Date: Tue, 17 Jun 2025 16:34:52 +0000
From: "Sean A." <sean@...e.io>
To: "john.g.garry@...cle.com" <john.g.garry@...cle.com>
Cc: "James.Bottomley@...senpartnership.com" <James.Bottomley@...senPartnership.com>, "atomlin@...mlin.com" <atomlin@...mlin.com>, "kashyap.desai@...adcom.com" <kashyap.desai@...adcom.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>, "martin.petersen@...cle.com" <martin.petersen@...cle.com>, "mpi3mr-linuxdrv.pdl@...adcom.com" <mpi3mr-linuxdrv.pdl@...adcom.com>, "sreekanth.reddy@...adcom.com" <sreekanth.reddy@...adcom.com>, "sumit.saxena@...adcom.com" <sumit.saxena@...adcom.com>
Subject: Re: [RFC PATCH v2 1/1] scsi: mpi3mr: Introduce smp_affinity_enable module parameter


Le 17 Jun 2025, John Garry a écrit :
> You have given no substantial motivation for this change

>From my perspective, workloads exist (defense, telecom, finance, RT etc) that prefer not to be interrupted and developers may opt to utilize CPU isolation and other mechanisms to reduce the likelihood of being pre-empted, evicted, etc. This includes steering interrupts away from an isolated set of cores. Also while this doesn't result from any actual benchmarking, it would seem that forcing your way on to every core in a 192 core system and refusing to move might be needlessly greedy or even detrimental to performance if most of the core set is NUMA-foreign to the storage controller. One should be able to make placement decisions to protect app threads from interruption and to ensure the interrupt handler has a sleepy, local core to play with without lighting up a bunch of interconnect paths on the way.

Generically, I believe interfaces like /proc/$pid/smp_affinity[_list] should be allowed to work as expected, and things like irqbalance should also be able to do their jobs unless there's a good (documented) reason they should not.
SA