From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3F537226CF7 for ; Thu, 18 Sep 2025 12:04:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758197086; cv=none; b=qsZajdJgRwtzIEp7moU6hcvglGLeI1z+g+oohXDAl/C2mu2HnCxZhkJ66mPfyOkaGAclSZjH5cDYgvCJse+aemwMhkCFTNyA52li7pYr/lLhRA+t3QAQrNOl/xcu6r9Rl3JUofroXYVK11VLOa7ieHz7UZQ2wRzEOrBVMmpKyeM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758197086; c=relaxed/simple; bh=7bqPA4HguqG2V/mtUuV6Bxv4IOqPNwnxHLf9K2YblqQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Jv6HHUekd1gm0QO5drf/FNv+o5Mj9xc2zV33mt+8gk8o639THCc+cvj6LbkTBpr3j3YgDnUajjebdpo3IW6XsosIxrm90g/F+qokl72QL9rLZXggMbJryM7/Dbl5oGuToFTtcbTRSN8vok/3kAYYGzyJGthY4jb2o97xn8It9c4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uAYbr0RZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uAYbr0RZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E7D5C4CEE7; Thu, 18 Sep 2025 12:04:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758197085; bh=7bqPA4HguqG2V/mtUuV6Bxv4IOqPNwnxHLf9K2YblqQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uAYbr0RZfNIcX2pIJZq0zFjTlRgdNWZjOjVWajZgjxyU9hrpq+0P8UnQ2q2MpWjuT 0iQ5Aa6huqFM3Cfi0xCdekFeqx1Q51s+dyNLnXWVZ+W6m1n8Ra3hU1DoMbLrScr1yq 07tLESzQD1LnsTH8f3w690rzip2yEnkxswoLnyRb0Wrp9z/B+SA3kgXDBn40+SWJT6 i2sFeURcZfOjFM/XFpUTxIzKsQ06+1X+NMhTqwGMWf7yoBwAukqJUd+ItJ/DEw+XjA AWOZ7ONjeyNFup5C9h4YBDZjSFbLZEFx8Lpn5V2eWAryhiERpp+evDabJyOS49fB0B AaymoU3tW1TmQ== Date: Thu, 18 Sep 2025 14:04:42 +0200 From: Frederic Weisbecker To: Waiman Long Cc: LKML , Ingo Molnar , Marco Crivellari , Michal Hocko , Peter Zijlstra , Tejun Heo , Thomas Gleixner , Vlastimil Babka Subject: Re: [PATCH 01/33] sched/isolation: Remove housekeeping static key Message-ID: References: <20250829154814.47015-1-frederic@kernel.org> <20250829154814.47015-2-frederic@kernel.org> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Le Fri, Aug 29, 2025 at 05:34:55PM -0400, Waiman Long a écrit : > > On 8/29/25 11:47 AM, Frederic Weisbecker wrote: > > The housekeeping static key in its current use is mostly irrelevant. > > Most of the time, a housekeeping function call had already been issued > > before the static call got a chance to be evaluated, defeating the > > initial call optimization purpose. > > > > housekeeping_cpu() is the sole correct user performing the static call > > before the actual slow-path function call. But it's seldom used in > > fast-path. > > > > Finally the static call prevents from synchronizing correctly against > > dynamic updates of the housekeeping cpumasks through cpusets. > > > > Get away with a simple flag test instead. > > > > Signed-off-by: Frederic Weisbecker > > --- > > include/linux/sched/isolation.h | 25 +++++---- > > kernel/sched/isolation.c | 90 ++++++++++++++------------------- > > 2 files changed, 55 insertions(+), 60 deletions(-) > > > > diff --git a/include/linux/sched/isolation.h b/include/linux/sched/isolation.h > > index d8501f4709b5..f98ba0d71c52 100644 > > --- a/include/linux/sched/isolation.h > > +++ b/include/linux/sched/isolation.h > > @@ -25,12 +25,22 @@ enum hk_type { > > }; > > #ifdef CONFIG_CPU_ISOLATION > > -DECLARE_STATIC_KEY_FALSE(housekeeping_overridden); > > +extern unsigned long housekeeping_flags; > > + > > extern int housekeeping_any_cpu(enum hk_type type); > > extern const struct cpumask *housekeeping_cpumask(enum hk_type type); > > extern bool housekeeping_enabled(enum hk_type type); > > extern void housekeeping_affine(struct task_struct *t, enum hk_type type); > > extern bool housekeeping_test_cpu(int cpu, enum hk_type type); > > + > > +static inline bool housekeeping_cpu(int cpu, enum hk_type type) > > +{ > > + if (housekeeping_flags & BIT(type)) > > + return housekeeping_test_cpu(cpu, type); > > + else > > + return true; > > +} > > + > > extern void __init housekeeping_init(void); > > #else > > @@ -58,17 +68,14 @@ static inline bool housekeeping_test_cpu(int cpu, enum hk_type type) > > return true; > > } > > +static inline bool housekeeping_cpu(int cpu, enum hk_type type) > > +{ > > + return true; > > +} > > + > > static inline void housekeeping_init(void) { } > > #endif /* CONFIG_CPU_ISOLATION */ > > -static inline bool housekeeping_cpu(int cpu, enum hk_type type) > > -{ > > -#ifdef CONFIG_CPU_ISOLATION > > - if (static_branch_unlikely(&housekeeping_overridden)) > > - return housekeeping_test_cpu(cpu, type); > > -#endif > > - return true; > > -} > > static inline bool cpu_is_isolated(int cpu) > > { > > diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c > > index a4cf17b1fab0..2a6fc6fc46fb 100644 > > --- a/kernel/sched/isolation.c > > +++ b/kernel/sched/isolation.c > > @@ -16,19 +16,13 @@ enum hk_flags { > > HK_FLAG_KERNEL_NOISE = BIT(HK_TYPE_KERNEL_NOISE), > > }; > > -DEFINE_STATIC_KEY_FALSE(housekeeping_overridden); > > -EXPORT_SYMBOL_GPL(housekeeping_overridden); > > - > > -struct housekeeping { > > - cpumask_var_t cpumasks[HK_TYPE_MAX]; > > - unsigned long flags; > > -}; > > - > > -static struct housekeeping housekeeping; > > +static cpumask_var_t housekeeping_cpumasks[HK_TYPE_MAX]; > > +unsigned long housekeeping_flags; > > Should we add the__read_mostly attribute to housekeeping_flags to prevent > possible false cacheline sharing problem? > > Other than that, LGTM Makes sense. Thanks. -- Frederic Weisbecker SUSE Labs