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 F309C35DA5B; Tue, 21 Apr 2026 18:43:50 +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=1776797031; cv=none; b=RmlUIEqpTy3KlzM6lnsQnH1ELZvyXzKSH3VdOAFLenWugglmrrKitEmYgr7z40wSesXX8pFzsEMd6JLJHSQFgH/LAV6/tWFk1gOe1Gy3GZEZP3lfpotxDVzLNN8wVBoD3wImYYswiHszVZE2ghbMNxr0AToeljJ/o3KSc2Kkm2E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776797031; c=relaxed/simple; bh=D9bO5NnHt3R2eni60hYUUr/AeT3qN1GRnjRSK4y+ECo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=NlEHqPaeA0yfzoWEwTYovb++l4+f2bHaqGK3A3fuCJkHn2KorX0GntUdD0gZ7OQB+BG87rM5otYU248RyHL8LY8Lq/KVyftpLzUT7NALAClSYU1VxJkBu/7TQQmmr0IjkyxiO6XFfrnygtopJp//NVfwjW7Ksq6xwI923I4OCn8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RpF/xhOX; 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="RpF/xhOX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9561AC2BCB0; Tue, 21 Apr 2026 18:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776797030; bh=D9bO5NnHt3R2eni60hYUUr/AeT3qN1GRnjRSK4y+ECo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RpF/xhOXQwrMYmPF95ZzDOkYwTBWNJp3iUkcjfRBYB0LpyWrCCiuRDfKlFhymW1UQ 6TOuSdalH39Zxv7ZQj0G0IyHHEgaA/YF+XUbmu7gfNazbz8YnPHY3GE4rs8+AUGipz aZirw4DaFoD6FMOWa06+XaDAkxRD9fx2FVaQ6XHO9mmSsiBXmsXBk9QH8hJPm+qaiP rcq+F6yumdX2DEEQaNL6n35fcf+nS7eRqb69WDhQlRGqa/I7egYe3Ll2In972DbiZJ eK2SF/BUcL85XKXUV9XBduFzTZV0k2a6OoYEIAJtmijoekrx9p1hnQP9Pxv9D1wIeb yIxK0DMJuV7aA== 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 Subject: Re: [PATCH 18/23] cpu/hotplug: Add a new cpuhp_offline_cb() API In-Reply-To: <4a0ede3e-6e87-414f-a3a3-dd15c32f25ef@redhat.com> References: <20260421030351.281436-1-longman@redhat.com> <20260421030351.281436-19-longman@redhat.com> <87o6jcb84w.ffs@tglx> <4a0ede3e-6e87-414f-a3a3-dd15c32f25ef@redhat.com> Date: Tue, 21 Apr 2026 20:43:46 +0200 Message-ID: <87340ob1ct.ffs@tglx> Precedence: bulk X-Mailing-List: linux-hwmon@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Apr 21 2026 at 13:29, Waiman Long wrote: > On 4/21/26 12:17 PM, Thomas Gleixner wrote: > Thanks for the great suggestions. I will certainly look into that. > > We actually have a cpu_active_mask that will be cleared early in > sched_cpu_deactivate(). In the CPUHP_AP_SCHED_WAIT_EMPTY state, the CPU > will still have online bit set but the active bit will be cleared. Or we > could add another cpumask that can be used to indicate CPUs that have > reached CPUHP_AP_SCHED_WAIT_EMPTY or below if necessary. Right. Active mask is immediately cleared when a CPU goes down so that the scheduler does not enqueue new tasks on it. But you can't use it for interrupts because on CPU up the mask must be up to date when irq_affinity_online_cpu() is invoked. The tick has the same constraints. So for interrupts this should be handled in CPUHP_AP_IRQ_AFFINITY_ONLINE both in the existing up and the new down callback. That can be a interrupt core local CPU mask which is updated on the callbacks with the sparse_irq_lock held. Same for the tick handover magic. Thanks, tglx