Re: [PATCH v16 0/9] blk: honor isolcpus configuration

["Ionut Nechita (Wind River)" <ionut.nechita@windriver.com>]

Hi Aaron, Daniel,

Thanks for respinning this and for the move to
"isolcpus=managed_irq_strict".

Just a heads-up that I have picked up v16 and am backporting it to the
6.18 LTS tree so I can exercise the new parameter on our PREEMPT_RT
configuration. The goal is to validate the end-to-end behaviour of
managed_irq_strict on multiqueue hardware (NVMe and SCSI) with isolated
cores, in particular:

  - managed IRQ affinity and the reserved pre/post vectors staying off
    the isolated set and confined to housekeeping CPUs;
  - the blk-mq hotplug guard that refuses to offline the last
    housekeeping CPU still serving an online isolated core;
  - queue/vector counts on systems where nr_vectors >= nr_cpus
    (narrow housekeeping pools, many PFs + NVMe).

I will follow up on this thread with results (effective_affinity and
blk-mq queue mapping data, plus any backport-specific findings) once
testing on 6.18 LTS is complete.

On the maintainer question (option 1 vs option 2): from a
downstream/product standpoint I favour option 1, keeping
"managed_irq_strict" as an explicit opt-in. Leaving the legacy
"managed_irq" semantics unchanged avoids a silent behavioural change
for existing deployments, while the strict variant gives new users a
clear, predictable knob.

Thanks for driving this forward.

Ionut