Re: [PATCH 10/10] drm/panthor: Introduce interrupt coalescing support for job IRQs

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 1 May 2026 15:57:35 +0100
Steven Price <steven.price@arm.com> wrote:

> On 29/04/2026 10:38, Boris Brezillon wrote:
> > Dealing with interrupts from the raw IRQ handler is good for latency,
> > but might be detrimental for the overall throughput, because the system
> > keeps being interrupted to process job interrupts.
> > 
> > Try to mitigate that with some interrupt coalescing infrastructure,
> > where we wake up the IRQ thread if close enough interrupts gets
> > detected.
> > 
> > It's still experimental, which explains why the feature is off by
> > default, and can be enabled through a debugfs knob.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>  
> 
> I think we need some more serious benchmarking to decide whether this is
> a good idea. We've experimented with coalescing interrupts in the past
> and it generally regressed some important benchmark of the day. But I'm
> not in the loop of "benchmark of the day" any more (although I do know
> that glmark hasn't been for years...) so it might have changed. From
> what I hear AI workloads "benefit"[1] from spinning a CPU waiting for
> jobs to finish.
> 
> [1] AI workloads don't tend to care so much about power... at least from
> the CPU.
> 
> One typo I spotted below. And I'm not awfully keen on the debugfs
> interface (but for testing it's obviously fine).

Yeah, just to be clear, patch 10 was really meant to be an RFC to get
the discussion started. What worries me a bit is the regression I'm
seeing on refract/terrain when switching to "event processing from the "
hard handler, which is why I worked on that.