From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8024AC5DF94 for ; Fri, 21 Aug 2026 16:37:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:MIME-Version: Content-Transfer-Encoding:Content-Type:References:In-Reply-To:Date:Cc:To:From :Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yfG+Ll5zHNYY65Is2tyZ/Rt+y2Qcmys112LwFNGQ7Hc=; b=Y24FzuDvYg5IbEGyWLGRAG8wbi R7ijTMUyIiFxQoM/zr41avmiyc2cJxDz9usyQhQdntaww1IDUP/HfnsRRn55wbV+OpcIRtBTj2CLU F49hPpkQjskHixsN77O+1Z7oeIm18FTRjVTg7nXbFW73V0UtHv++wYk7BwOOeCJIQ4b8xvSapFDEh A80riOfz4omMPJUme4Kw/dqt+DPTpuH12samwjjcOU2q7R7+jlSNKIFlD27ab6QZblKrYezffHQjP TEYaYQXEs65jeo+3ECcP74EJd+o2t0yoPnoRCq1nfZgwvmeYfZ46iFCUPb5tfjwgGbWNikthwY2X2 GTy/1Gbg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wxSEw-0000000Dpsy-20dY; Fri, 21 Aug 2026 16:37:10 +0000 Received: from mta-64-226.siemens.flowmailer.net ([185.136.64.226]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wxSEt-0000000DpsA-0QGW for linux-arm-kernel@lists.infradead.org; Fri, 21 Aug 2026 16:37:09 +0000 Received: by mta-64-226.siemens.flowmailer.net with ESMTPSA id 2026082116370009aacc0c2d000207b4 for ; Fri, 21 Aug 2026 18:37:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm2; d=siemens.com; i=florian.bezdeka@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc:References:In-Reply-To; bh=yfG+Ll5zHNYY65Is2tyZ/Rt+y2Qcmys112LwFNGQ7Hc=; b=GinLcmo4MqViQsY0YMOV0adGreQymPsYZc2Qh/MpRHeNgYABULfb19cIb6CCS9HcBGYDRb 9VF7+4O5Cv9q5tspNribDKy6b9C8dNI6zHqVTYLQ/oYeJKsvud82ZupvoM5b/xL8t3l9aF63 YcAg0YRcJZgCE8sxdGDND0KaARrf043x10kC+1fTlX28Aa31DberPTJismRInP7n87sapxrW TOrBBOsYemy5SxnCkCx4HaUhb0MqOZ2uULcY+ZMr5iftUwkItMJ6hClaRrcmFXAJage9WKhQ rWTuC4eNcR7JXqr8HXxUPDVZk6JPESugJwBrDw1Yvw1n0rrAvnLvcilw==; Message-ID: <83c18ac5b726769c36b79dcd430198076b3da1a2.camel@siemens.com> Subject: Re: [PATCH RFC 1/3] cpumask: Honor irq_default_affinity in cpumask_local_spread() From: Florian Bezdeka To: Yury Norov Cc: Maxime Chevallier , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Yury Norov , Rasmus Villemoes , Andrew Morton , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Thomas Gleixner , Jan Kiszka , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Date: Fri, 21 Aug 2026 18:36:59 +0200 In-Reply-To: References: <20260819-flo-net-7-2-make-stmmac-default-affinity-aware-v1-0-3f79a99cadaf@siemens.com> <20260819-flo-net-7-2-make-stmmac-default-affinity-aware-v1-1-3f79a99cadaf@siemens.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-68982:519-21489:flowmailer X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260821_093707_751059_EBAC90C0 X-CRM114-Status: GOOD ( 27.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Yury, On Wed, 2026-08-19 at 14:38 -0400, Yury Norov wrote: > On Wed, Aug 19, 2026 at 04:30:30PM +0200, Florian Bezdeka wrote: > > Many drivers call cpumask_local_spread() to spread IRQs to several > > CPUs, mainly to get best performance and balance CPU load. For > > realtime (PREEMPT_RT) and other cpu-isolating workloads the old > > implementation was triggering an IRQ placement problem. IRQs were > > targeting CPUs that were isolated for those sensitive workloads. > >=20 > > Userland will tell the kernel about the desired IRQ configuration > > for new interrupts by writing a proper cpumask to > > /proc/irq/default_smp_affinity. This cpu mask has to be honored to > > avoid IRQ noise on isolated cores. > >=20 > > The default for irq_default_affinity is "all CPUs". So all CPUs will > > be taken into account for spreading when userland did not configure > > something special. > > --- > > lib/cpumask.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > >=20 > > diff --git a/lib/cpumask.c b/lib/cpumask.c > > index 5adb9874fbd0f5a42ea8cd9e6c3729a70599781f..73e7b60a9201174f83df606= 7effbe7d1889dcdb9 100644 > > --- a/lib/cpumask.c > > +++ b/lib/cpumask.c > > @@ -6,6 +6,7 @@ > > #include > > #include > > #include > > +#include > > =20 > > /* These are not inline because of header tangles. */ > > #ifdef CONFIG_CPUMASK_OFFSTACK > > @@ -81,8 +82,9 @@ void __init free_bootmem_cpumask_var(cpumask_var_t ma= sk) > > * @i: index number > > * @node: local numa_node > > * > > - * Return: online CPU according to a numa aware policy; local cpus are= returned > > - * first, followed by non-local ones, then it wraps around. > > + * Return: online CPU according to the default IRQ affinity and a numa= aware > > + * policy; local cpus are returned first, followed by non-local ones, = then it > > + * wraps around. > > * > > * For those who wants to enumerate all CPUs based on their NUMA dista= nces, > > * i.e. call this function in a loop, like: > > @@ -110,9 +112,9 @@ unsigned int cpumask_local_spread(unsigned int i, i= nt node) >=20 > Please don't touch this function. There's ~40 users, and we don't want > to inspect every caller for their intention. Yes and no. Yes: Your suggestions / concerns are valid. Noted. No: I'm expecting a revisit of all those usages. All "affected" drivers need to be fixed / addressed at the end, so we have to check all of them and migrate them. Sebastian also commented on this meanwhile. I'm fine with migrating affected drivers one by one. Makes sense. But before we start the migration process I'm still missing the "plan" or "vision". Which way do we want to go? Let's see if there is more input coming. Should drivers really deal with those cpumasks? I don't think so - at the moment. Thanks, highly appreciated. Florian