From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 6757F1946C8 for ; Thu, 16 Jan 2025 09:24:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737019451; cv=none; b=TTxI9snJOfWnA0X2172gY5LeKnljn4B/MsJqOuLeee1YZcIkTm96qR4EE/OrBJneWNcydK7iHHnseKVi+g6vRXAWyoiKNHrbNviztuMB6WTG+9sm8TQpa//9h0AvEEch7PbW4yFszNYXX1k2GaC1TS7FH7O7mQujf4pfUYZEFn4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737019451; c=relaxed/simple; bh=kvMCaqJ1SQNPg26BlFFspfk9YnbcyxlaT7N6TOfrYAw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OLkgo5rvHkZCJz6SLHak5BzR3JwJlDZ0ScRGD/QlOe6B+LVfPPFM6aXhk4jth1HOT+Ovj9MFpFd1AS3OABIJAqKnx8RKaVfUZcYOdwAHLfZZCAH1aZB1W3Kxlf713nYvuj7D58Ed3ln8JZr+fEowgHbhcTh1+Go/I/E7n11KMvs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=kooz8uIB; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=HIZaqape; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="kooz8uIB"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="HIZaqape" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1737019448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kvMCaqJ1SQNPg26BlFFspfk9YnbcyxlaT7N6TOfrYAw=; b=kooz8uIBd0FrEDO8Q27tTpz9p8CXeWiCCAd7Gi8d3Jcz5gkImafeb8dd8Kkj2ijWoS+0pI a4ofCU6iBvnSc+jjp++AYVrdaAjiz8jRO9N3oFCemiXNlPSIm85Per7+kOD3RXCfgeXaT+ En6b9nUZRwRXytBpuFcu89dWCi7BGTz+n8G3mKewcmORxrm/QVVAsBKClg5keiAM/byjTh nNP0JCXcGFpudCTnYMmyq1Gtsqo+NvnOiKVxuuoeMK8fZTLBTS9Mrn41Im2pQxMV0fseeh zhnrjP+n+ZV6Dj2WiCwvmc/gwH0MU2whAwXN/rTSft2kuN3ru4Nf8AsgVI2W0w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1737019448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kvMCaqJ1SQNPg26BlFFspfk9YnbcyxlaT7N6TOfrYAw=; b=HIZaqapep0TpwlH4wGEkxbs8k+dMSh1iBMkaFMaatWQSt6QAkD62mIqLphAFjgyMYAhStT ubwSUqw77eD/mBDw== To: Koichiro Den , linux-kernel@vger.kernel.org Cc: anna-maria@linutronix.de, frederic@kernel.org, peterz@infradead.org Subject: Re: [PATCH] hrtimer: reset .hres_active and .online at appropriate points In-Reply-To: <878qrbazki.ffs@tglx> References: <20241220134421.3809834-1-koichiro.den@canonical.com> <878qrbazki.ffs@tglx> Date: Thu, 16 Jan 2025 10:24:07 +0100 Message-ID: <875xmfaz7s.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Jan 16 2025 at 10:16, Thomas Gleixner wrote: > On Fri, Dec 20 2024 at 22:44, Koichiro Den wrote: >> Reset these fields at the appropriate points. Ideally, .hres_active >> would be reset in tick_cpu_dying() as underlying clockevent is shut down >> there. However, since these operations occur in the atomic AP section >> with interrupts disabled in any case, this patch resets .hres_active to >> 0 in hrtimers_cpu_dying() for simplicity. > > It does not matter where it is reset and from a hrtimer point of view > the dying() callback is the appropriate place. That said. The change is actually incomplete as the other fields which are related to the per CPU base state are not reset either.