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 BC1C4301033 for ; Tue, 2 Dec 2025 06:26:37 +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=1764656797; cv=none; b=RKq824XIT3qSItgkL9Tv8mHOQ8i7sEJCKMby0XjTvlr6SWeNrPa1Enx4OXP7E1voJTVR3vvKaSbn+iIf1RBdyrBcMVS7HXRDx6pplbKRlQUiUU+CzFyneBvP4e1PsFdBc9WdG+4V20g7HXjToJya79TRjmsnXFTQwTVt+57LyCU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764656797; c=relaxed/simple; bh=7tM8G4oPKjuLKovlZzA/tu5DjJG5mGz28BVFRDplKXM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=d7gOjp/8+kVWdUL6rNRFk1MO+crTIJGEmRo9VRx9oE7BqOuxgXekIk7Q7a6RwIXBCoKGE+mGjfFzgIisZvpDHwqOSN5FKlqWT8NLqHND/l2bSjflXGEWT6ieSfgz8kt+sZXwMO0vVhYOxMuY/nBGPjFW5S2ME1APdzGk4vfwnbg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G7WCCGCF; 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="G7WCCGCF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF722C4CEF1; Tue, 2 Dec 2025 06:26:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764656797; bh=7tM8G4oPKjuLKovlZzA/tu5DjJG5mGz28BVFRDplKXM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G7WCCGCFx9kdnnk2ijgG0Wf+IQYwI/SMzHFxPsSYcponR6o8jX63KBKbXm3jdlaQJ 9oYulwM9NliGzZwsP9A4cXh6Ibt+wdflZVjz1vXEOyl8Xfq6XAyqOLhbRKUzOxDcBR RdbPgDZbfa64rfGBDB5xLWdjOunFGwiZj8jmwPIvdz6/lYiXIwo7I5MCbkjuRXd5P7 KneDRBHjOQYIpVJIm+rO3Twd2Mp4QU2sF2kZfaBkFwRsUTek8fteGUGBfuyKgsNAew 9ueMW6BhfqS4Mm4CWwaC2EipvEkPzv8k4LcPa3kEZa6pQ2kPj7C6F0I2llGcGit9yw cFTrSjKmNCBLQ== Date: Tue, 2 Dec 2025 07:26:32 +0100 From: Ingo Molnar To: Shrikanth Hegde Cc: peterz@infradead.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, kprateek.nayak@amd.com, dietmar.eggemann@arm.com, vschneid@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, tim.c.chen@linux.intel.com Subject: Re: [PATCH 3/4] sched/fair: Check for blocked task after time check Message-ID: References: <20251201183146.74443-1-sshegde@linux.ibm.com> <20251201183146.74443-4-sshegde@linux.ibm.com> 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-Disposition: inline In-Reply-To: <20251201183146.74443-4-sshegde@linux.ibm.com> * Shrikanth Hegde wrote: > nohz.has_blocked can be updated often as and when CPUs enter idle state. > But stats are updated only at regular intervals. Usually fixed to > LOAD_AVG_PERIOD=32. > > Read the value only after time check is successful to avoid cache > references to it. > > Signed-off-by: Shrikanth Hegde > --- > kernel/sched/fair.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 55746274af06..5534822fd754 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -12440,8 +12440,8 @@ static void nohz_balancer_kick(struct rq *rq) > */ > nohz_balance_exit_idle(rq); > > - if (READ_ONCE(nohz.has_blocked) && > - time_after(now, READ_ONCE(nohz.next_blocked))) > + if (time_after(now, READ_ONCE(nohz.next_blocked)) && > + READ_ONCE(nohz.has_blocked)) > flags = NOHZ_STATS_KICK; So this patch makes no sense, as the two fields [1] and [2] are almost next to each other: static struct { cpumask_var_t idle_cpus_mask; // 0 atomic_t nr_cpus; // 8 int has_blocked; /* Idle CPUS has blocked load */ <========== [1] // 12 int needs_update; /* Newly idle CPUs need their next_balance collated */ // 16 unsigned long next_balance; /* in jiffy units */ // 24 unsigned long next_blocked; /* Next update of blocked load in jiffies */ <========== [2] // 32 } nohz ____cacheline_aligned; ... and thus they very likely share the same cacheline and there can be no reduction in cacheline bouncing from this change. In fact with OFFSTACK=y the cpumask_var_t is 8 bytes and thus the offset of the two fields will be 12 and 32 within the same 64-byte cacheline, guaranteed. I've marked the field offsets in the rightmost column for this case. Thanks, Ingo