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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-10-15 13:22:35 [+0200], Daniel Wagner wrote:
> During Plumbers we had several discussions on this series. This is what I
> remember we discussed and decided:
> 
>   - The current managed_irq behavior doesn't match the other flags of isolcpus.
> 
>   - Instead of introducing managed_irq_strict, it's better to change the
>     existing managed_irq to follow the strict interpretation.
> 
>   - The main existing user of the current managed_irq mapping is
>     RH with OpenShift. After discussing with Juri, it doesn't look like
>     it is a real blocker to change to the strict interpretation.

This is what I remember, too.

>   - If there are complaints about the managed irq behavior change, it's
>     better to introduce a different flag for this. Though there have been
>     many discussions and proposals on how to deal with isolation during the
>     conference, and the general mood was that the placement of resources
>     should be done during runtime. Thus it is likely that the old behaviour
>     is not necessary at all if runtime configuration is possible.

The main argument/ problem is that managed_irq does not work as expected
for the vast majority of users and should be fixed. This has only been
"recently" documented.

The whole isolcpus= was meant to be static and there was no argument why
it needs to vanish. A dynamic interface for dynamic workloads is what
you want especially if you have 80+ CPUs and workloads can change. But
on <16 CPUs system the partition probably do not change. It is also not
obvious if your driver(s) use managed_irqs or not.
To get a runtime interface for this you would need to be able to
reconfigure the managed_irq interrupt if "interrupts < CPUS". Otherwise
it is just enable and disable like during CPU-hotplug but without it. If
I remember it correctly, the device itself does not handle this at all
but the block layers drains and starts queues during a hotplug event.

> Hope this helps to move forward with this series,
> Daniel

Sebastian