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

[Daniel Wagner <dwagner@suse.de>]

On Thu, Sep 10, 2026 at 12:42:28PM -0400, Aaron Tomlin wrote:
> Maintainer guidance requested
> =============================
> 
> We would appreciate guidance from Frederic Weisbecker regarding preference
> on this front:
>         1.  Do you prefer keeping "managed_irq_strict" as an explicit
>             opt-in (as implemented in this series) to preserve historical
>             behaviour for existing users of "managed_irq"?
> 
>         2.  Or would you prefer upgrading the semantics of "managed_irq"
>             directly in place without introducing a new parameter, on the
>             grounds that the legacy post-allocation behaviour is already
>             broken for modern multiqueue hardware?

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.

  - 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.

Hope this helps to move forward with this series,
Daniel