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 EB9873A0B26; Tue, 21 Apr 2026 08:55:24 +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=1776761725; cv=none; b=Ktt6QSi8cX9iMazALWVVwxqE+fte193TaeGYWS56V6a1+khp0nkwMsqdYnIAzY73mJ6RQyIaR/ADTNxs8N9ctiaeKiu70umGDQaSudGT6qDMbqIQGghuUcdBypc6dXDBtDWfoxptn1/w6yAFE7YL0+P7Rca8YftAhVMEkp5T+Js= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776761725; c=relaxed/simple; bh=l8GZGmmqBDH1qGsf6cYl9us7elj7guWOOnOWIKaH7fk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=LQXUIn2KRcNjQ/HU8n3IJnikYGldYrolaecUwIogYuR22wWG7ihZ1INIcSBQs2U/SlCzjaXOYgTH8Hf/xwavn+nypIlwEw/yppGp2/VbzGLXCxopfe3qVE/VvJM6daeruIiRQh+KBBWqPPBnvvFBlIngVOD84XTTUeIkcFueIa4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fbpksxB6; 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="fbpksxB6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85CDAC2BCB8; Tue, 21 Apr 2026 08:55:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776761724; bh=l8GZGmmqBDH1qGsf6cYl9us7elj7guWOOnOWIKaH7fk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fbpksxB6uMfX5Z5L/PjhReWfZqK/gZWcUtb6VpyahD6lNkPwvC53AyuHNjTxumI8b duF/nj30nw15WGdGP4wWI4cZJCvOgrppPsKLO6W+438xfzolOxyCQLWWtiYuogohr7 1GDeU1agc/WykWiBDwQk3/ghICVktpzs8vPBU7Tvr2uroNjLOAaVtsZ6e+UsS6+SR5 95XzgmP+zGCzUnqFAOB6rIyVPGOklw1+f4w+gBdEsc12hGeD/BpK2xSmQq0Zb+Rnza sqCn0XnOQ9Fo3G6EZr6k66TGFrZQhFMgK4Uh4hpsPC1v1fOZ6Hq/roWwfxmW6uWky3 HX57nFht2oNNw== From: Thomas Gleixner To: Waiman Long , Tejun Heo , Johannes Weiner , Michal =?utf-8?Q?Koutn=C3=BD?= , Jonathan Corbet , Shuah Khan , Catalin Marinas , Will Deacon , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Guenter Roeck , Frederic Weisbecker , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Anna-Maria Behnsen , Ingo Molnar , Chen Ridong , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hyperv@vger.kernel.org, linux-hwmon@vger.kernel.org, rcu@vger.kernel.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, Costa Shulyupin , Qiliang Yuan , Waiman Long Subject: Re: [PATCH 05/23] tick: Pass timer tick job to an online HK CPU in tick_cpu_dying() In-Reply-To: <20260421030351.281436-6-longman@redhat.com> References: <20260421030351.281436-1-longman@redhat.com> <20260421030351.281436-6-longman@redhat.com> Date: Tue, 21 Apr 2026 10:55:21 +0200 Message-ID: <87zf2wbsli.ffs@tglx> Precedence: bulk X-Mailing-List: cgroups@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Apr 20 2026 at 23:03, Waiman Long wrote: > In tick_cpu_dying(), if the dying CPU is the current timekeeper, > it has to pass the job over to another CPU. The current code passes > it to another online CPU. However, that CPU may not be a timer tick > housekeeping CPU. If that happens, another CPU will have to manually > take it over again later. Avoid this unnecessary work by directly > assigning an online housekeeping CPU. > > Use READ_ONCE/WRITE_ONCE() to access tick_do_timer_cpu in case the > non-HK CPUs may not be in stop machine in the future. 'may not be in the future' is yet more handwaving without content. Please write your change logs in a way so that people who have not spent months on this can follow. > @@ -394,12 +395,19 @@ int tick_cpu_dying(unsigned int dying_cpu) > { > /* > * If the current CPU is the timekeeper, it's the only one that can > - * safely hand over its duty. Also all online CPUs are in stop > - * machine, guaranteed not to be idle, therefore there is no > + * safely hand over its duty. Also all online housekeeping CPUs are > + * in stop machine, guaranteed not to be idle, therefore there is no > * concurrency and it's safe to pick any online successor. > */ > - if (tick_do_timer_cpu == dying_cpu) > - tick_do_timer_cpu = cpumask_first(cpu_online_mask); > + if (READ_ONCE(tick_do_timer_cpu) == dying_cpu) { > + unsigned int new_cpu; > + > + guard(rcu)(); What's this guard for? > + new_cpu = cpumask_first_and(cpu_online_mask, housekeeping_cpumask(HK_TYPE_TICK)); Why has this to use housekeeping_cpumask() and does not use tick_nohz_full_mask? Thanks, tglx