From nobody Tue Oct 7 16:34:27 2025 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (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 B0DE52E5416 for ; Tue, 8 Jul 2025 16:23:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.189 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751991832; cv=none; b=uZoc/xMnsBocxTYteqOzhy6fnxEUitwio4aUePYSaj4ztSMSdhksnz5xdoh6n6dK3+EQDH1Ftn76D6/GfeqgGpWW19tIgnt5patzQSwb4kz3bdUjDOt7yk8OPduXGL7YZwVhTghO3VPMDjlvjvlFstRgcqzB3vi3/u5TNMkkCG8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751991832; c=relaxed/simple; bh=MtGa2Y+6oxSfcCiplPxDDTowkK7ULExVJ7p8Jx+X+ZA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=pQwpXLFllwJ7IBdk07Y2I5N1+nLt5VID4iIqMViSZHHCj52WwognwachDqIQds3IHn2L2iyfvHSiAGJjGJfjZZ9HBFXq6UqPBP4bjOgMmvuApA6KoioIAJTKTxXJlj0JZBK9BwjjqvxUM0H81oXdESKo0nmcflrItOBRamV43fY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4bc5sn6t2Rz1rqRn; Wed, 9 Jul 2025 00:19:41 +0800 (CST) Received: from kwepemf200003.china.huawei.com (unknown [7.202.181.229]) by mail.maildlp.com (Postfix) with ESMTPS id AFECA180466; Wed, 9 Jul 2025 00:23:45 +0800 (CST) Received: from kwepemh100012.china.huawei.com (7.202.181.97) by kwepemf200003.china.huawei.com (7.202.181.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 9 Jul 2025 00:23:45 +0800 Received: from kwepemh100012.china.huawei.com ([7.202.181.97]) by kwepemh100012.china.huawei.com ([7.202.181.97]) with mapi id 15.02.1544.011; Wed, 9 Jul 2025 00:23:45 +0800 From: "Wangshaobo (bobo)" To: Frederic Weisbecker , "wangxiongfeng (C)" CC: "anna-maria@linutronix.de" , "tglx@linutronix.de" , "linux-kernel@vger.kernel.org" , Xiexiuqi Subject: =?gb2312?B?tPC4tDogW1BBVENIXSBocnRpbWVyczogVXBkYXRlIG5ldyBDUFUncyBuZXh0?= =?gb2312?B?IGV2ZW50IGluIGhydGltZXJzX2NwdV9keWluZygp?= Thread-Topic: [PATCH] hrtimers: Update new CPU's next event in hrtimers_cpu_dying() Thread-Index: AQHb7+1OehEg9pjwRU2FlbA4UgYjRLQnpQoAgADC4MA= Date: Tue, 8 Jul 2025 16:23:45 +0000 Message-ID: References: <20250708101727.166892-1-wangxiongfeng2@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Transfer-Encoding: quoted-printable 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="utf-8" -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Frederic Weisbecker [mailto:frederic@kernel.or= g]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2025=E5=B9=B47=E6=9C=888=E6=97=A5 20:= 41 =E6=94=B6=E4=BB=B6=E4=BA=BA: wangxiongfeng (C) =E6=8A=84=E9=80=81: anna-maria@linutronix.de; tglx@linutronix.de; linux-ker= nel@vger.kernel.org; Xiexiuqi ; Wangshaobo (bobo) =E4=B8=BB=E9=A2=98: Re: [PATCH] hrtimers: Update new CPU's next event in hr= timers_cpu_dying() Le Tue, Jul 08, 2025 at 06:17:27PM +0800, Xiongfeng Wang a =C3=A9crit : > When testing softirq based hrtimers on an ARM32 board, with high=20 > resolution mode and nohz are both inactive, softirq based hrtimers=20 > failed to trigger when moved away from an offline CPU. The flowpath is=20 > as follows. >=20 > CPU0 CPU1 > softirq based hrtimers are queued > offline CPU1 > move hrtimers to CPU0 in hrtimers_cpu_dying() > send IPI to CPU0 to retrigger next event 'softirq_expires_next' is=20 > KTIME_MAX call retrigger_next_event() highres and nohz is=20 > inactive,just return 'softirq_expires_next' is not updated hrtimer=20 > softirq is never triggered >=20 > Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. > hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it=20 > send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high=20 > resolution mode and nohz are both inactive. So retrigger_next_event()=20 > just returned. 'softirq_expires_next' is never updated and remains=20 > KTIME_MAX. So hrtimer softirq is never raised. >=20 > To fix this issue, we call hrtimer_update_next_event() in > hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. > It also update hardirq hrtimer's next event, but it should have no bad=20 > effect. >=20 > Fixes: 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from=20 > outgoing CPU earlier") > Signed-off-by: Xiongfeng Wang > --- > kernel/time/hrtimer.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) >=20 > diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index=20 > 30899a8cc52c..ff97eb36c116 100644 > --- a/kernel/time/hrtimer.c > +++ b/kernel/time/hrtimer.c > @@ -2298,8 +2298,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) > /* > * The migration might have changed the first expiring softirq > * timer on this CPU. Update it. > + * We also need to update 'softirq_expires_next' here, because it will > + * not be updated in retrigger_next_event() if high resolution mode > + * and nohz are both inactive. > */ > - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); > + hrtimer_update_next_event(new_base); > /* Tell the other CPU to retrigger the next event */ > smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); It seems that a similar problem can happen while enqueueing a timer from an= offline CPU (see the call to smp_call_function_single_async()). How about this (untested) instead? retrigger_next_event, is not a fast path= so we don't care about rare extra cost: diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 30899a8cc5= 2c..e8c479329282 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -787,10 +787,10 @@ static void retrigger_next_event(void *arg) * of the next expiring timer is enough. The return from the SMP * function call will take care of the reprogramming in case the * CPU was in a NOHZ idle sleep. + * + * In periodic low resolution mode, the next softirq expiration + * must also be updated. */ - if (!hrtimer_hres_active(base) && !tick_nohz_active) - return; Could you explain in detail why this judgment is added? Is it due to securi= ty issues or efficiency impact? - Wang ShaoBo raw_spin_lock(&base->lock); hrtimer_update_base(base); if (hrtimer_hres_active(base)) @@ -2295,11 +2295,6 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) &new_base->clock_base[i]); } =20 - /* - * The migration might have changed the first expiring softirq - * timer on this CPU. Update it. - */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); =20