Re: [PATCH] irq: fasteoi handler re-runs on concurrent invoke

["Gowans, James" <jgowans@amazon.com>]

On Wed, 2023-03-22 at 14:26 +0800, Yipeng Zou wrote:
> > 在 2023/3/17 19:49, Gowans, James 写道:
> > What are your thoughts on this approach compared to your proposal?
> 
> Hi,
> 
> I also agree with you, enhance the existing generic handlers is a good
> way to go.
> 
> Too many generic handlers really confuse developers.

Thomas, would you be open to taking the patch to tweak the handle_fasteoi_irq
handler? Or is there a different solution to this problem which you prefer?

> About CONFIG_GENERIC_PENDING_IRQ is actually some attempts we made
> before under the suggestion of Thomas.
> 
> This patch is valid for our problem. However, the current config is only
> supported on x86, and some code modifications are required on arm.

Thanks for the patch! I have been trying out CONFIG_GENERIC_PENDING_IRQ too, but
couldn't get it to work; it seems the IRQ never actually moved. I see from your
patch that we would need to tweak the callbacks and explicitly do the affinity
move in the EOI handler of the chip; the generic code won't do it for us.

> This has led to some changes in the original behavior of modifying
> interrupting affinity, from the next interrupt taking effect to the next
> to the next interrupt taking effect.

So this means that even if it's safe to change the affinity right now, the
change will actually be delayed until the *next* interrupt? Specifically because
interrupt doesn't have the IRQD_MOVE_PCNTXT state flag isn't set hence
irq_set_affinity_locked won't call irq_try_set_affinity?


JG