From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D49D345734 for ; Mon, 4 May 2026 11:15:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777893328; cv=none; b=PSNsf/DbobpNO0Rm3xwETI14Pj+HM4gzyqXNYG21n5ttB9U3H0uOJodEWzdAQkM1Ky9bTajiOPtV0bung6wi/yqyAfOfZfFEh5BIIBkYre5fekic94vesXxsyQm3YMfl2V75pNZNa4jtXLNcgQZAppkwGY3SIjFE9agASynZ4o4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777893328; c=relaxed/simple; bh=DFybYs16j+UQIzyKR0NoGVrbwoeuu7MHZgrH7CxDzrs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NFcHGRW3KdPek8cSEIjq/eNDBr/9RqVNByJKegDz8vWimSdhhpTPYVTGtALzkJJrhb46OmSsdJOAbs1BDKfxBWrluvYlu6MlbzXBtvi0Ul0uIQekQvJPUpJPD/D4CapZnFJDnL/UG5DhmPtjUgbnkDyOkU4A5T9vbWbTK9bnJQc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=Ml8EFgm3; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="Ml8EFgm3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1777893325; bh=DFybYs16j+UQIzyKR0NoGVrbwoeuu7MHZgrH7CxDzrs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ml8EFgm3Dqvo2K7U7yzB86T+hWTbSJ6oOraN7sHtU2bW9Q5AHUnsDcTW9nGBl71AI qLgT8olXlr6WGIC7tc2jKWK5jFC3/HRHLNgbwHmTbPEjS0IkBaWXWIp2uMENXEuRnF j1JO6xT6Gw7dnX9TXSy06x5yXzanSJ8NTpZqrcc1usFzowFqpJRlsxyCgPkJqc9E5K SrbrrtqFCrdgyXHO++JBUaKvJw5qWzQcgbMePLZJ3Xl7DXi502BdP56eNDbXl4xlXI YWmd0nebTYW2BWJaOckM7bNM3+leC17ylUcVR0Awbv1CBfYCxddS238JnLwQ/EyEgi pNxD54cBv0zcw== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 5D29517E1305; Mon, 4 May 2026 13:15:25 +0200 (CEST) Date: Mon, 4 May 2026 13:15:21 +0200 From: Boris Brezillon To: Steven Price Cc: Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/10] drm/panthor: Introduce interrupt coalescing support for job IRQs Message-ID: <20260504131521.49f4750d@fedora> In-Reply-To: References: <20260429-panthor-signal-from-irq-v1-0-4b92ae4142d2@collabora.com> <20260429-panthor-signal-from-irq-v1-10-4b92ae4142d2@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 1 May 2026 15:57:35 +0100 Steven Price 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 > > 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.