On Mon, 2019-11-18 at 10:49 +0000, Lorenzo Pieralisi wrote: > On Wed, Nov 06, 2019 at 08:33:01PM +0000, Derrick, Jonathan wrote: > > On Thu, 2019-11-07 at 05:27 +0900, Keith Busch wrote: > > > On Wed, Nov 06, 2019 at 08:14:41PM +0000, Derrick, Jonathan wrote: > > > > Yes that problem exists today > > > > > > Not really, because we're currently using unamanged interrupts which > > > migrate to online CPUs. It's only the managed ones that don't migrate > > > because they have a unchangeable affinity. > > > > > > > and this set limits the exposure as it's > > > > a rare case where you have a child NVMe device with fewer than 32 > > > > vectors. > > > > > > I'm deeply skeptical that is the case. Even the P3700 has only 31 IO > > > queues, yielding 31 vectors for IO services, so that already won't work > > > with this scheme. > > > > > Darn you're right. At one point I had VMD vector 1 using NVMe AQ, > > leaving the 31 remaining VMD vectors for NVMe IO queues. This would > > have lined up perfectly. Had changed it last minute and that does break > > the scheme for P3700.... > > > > > But assuming you wanted to only use devices that have at least 32 IRQ > > > vectors, the nvme driver also allows users to carve those vectors up > > > into fully affinitized sets for different services (read vs. write is > > > the one the block stack supports), which would also break if alignment > > > to the parent device's IRQ setup is required. > > > > Wasn't aware of this. Fair enough. > > Marked the series with "Changes Requested", waiting for a new > version. > > Lorenzo This will need an entirely different strategy to be useful, so can be dropped for now. Thank you, Jon
