mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Frederic Weisbecker <frederic@kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"Russell King (Oracle)" <linux@armlinux.org.uk>,
	Joel Fernandes <joel@joelfernandes.org>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, kernel-team@meta.com,
	paulmck@kernel.org, mingo@kernel.org, rcu@vger.kernel.org,
	neeraj.upadhyay@amd.com, urezki@gmail.com,
	qiang.zhang1211@gmail.com, bigeasy@linutronix.de,
	chenzhongjin@huawei.com, yangjihong1@huawei.com,
	rostedt@goodmis.org, Justin Chen <justin.chen@broadcom.com>
Subject: Re: [PATCH] timer/migration: Remove buggy early return on deactivation [was Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9]]
Date: Fri, 15 Mar 2024 06:44:56 -0700	[thread overview]
Message-ID: <1c5227a6-6b22-46c5-9966-d35ac1c770af@gmail.com> (raw)
In-Reply-To: <ZfOhB9ZByTZcBy4u@lothringen>



On 3/14/2024 6:14 PM, Frederic Weisbecker wrote:
> On Thu, Mar 14, 2024 at 03:05:53PM -0700, Boqun Feng wrote:
>> I notice CPU3 didn't have its own non-deferrable timer queued (local or
>> global), so could the following happen?
>>
>> 	timer_base_try_to_set_idle():
>> 	  __get_next_timer_interrupt():
>> 	    fetch_next_timer_interrupt():
>> 	      // nextevt_local == nextevt_global == basej + NEXT_TIMER_MAX_DELTA
>> 	      // tevt->local == tevt->gloabl = KTIME_MAX
>> 	    timer_use_tmigr():
>> 	      tmigr_cpu_deactivate():
>> 	        __tmigr_cpu_deactivate():
>> 		  // tmc->cpuevt.ignore untouched still == true
>> 		  walk_groups(&tmigr_inactive_up, ...):
>> 		    tmigr_inactive_up():
>> 		      data->remote = true;
>> 		      tmigr_update_events():
>> 		        if (child) { // child is NULL
>> 			  ...
>> 			} else {
>> 			  first_childevt = evt = data->evt;
>>
>> 			  if (evt->ignore && !remote)
>> 			    return true; // no remote tick is picked.
>> 			  ...
>> 			}
> 
> Nice catch! Florian can you try the following?
> 
>  From b0e335371ed758f68bf4f501246298c98a615b04 Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker <frederic@kernel.org>
> Date: Fri, 15 Mar 2024 00:21:01 +0100
> Subject: [PATCH] timer/migration: Remove buggy early return on deactivation
> 
> When a CPU enters into idle and deactivates itself from the timer
> migration hierarchy without any global timer of its own to propagate,
> the group event of that CPU is set to "ignore" and tmigr_update_events()
> accordingly performs an early return without considering timers queued
> by other CPUs.
> 
> If the hierarchy has a single level, and the CPU is the last one to
> enter idle, it will ignore others' global timers, as in the following
> layout:
> 
>             [GRP0:0]
>           migrator = 0
>           active   = 0
>           nextevt  = T0i
>            /         \
>           0           1
>        active (T0i)  idle (T1)
> 
> 0) CPU 0 is active thus its event is ignored (the letter 'i') and so are
> upper levels' events. CPU 1 is idle and has the timer T1 enqueued.
> 
>             [GRP0:0]
>           migrator = NONE
>           active   = NONE
>           nextevt  = T0i
>            /         \
>           0           1
>        idle (T0i)  idle (T1)
> 
> 1) CPU 0 goes idle without global event queued. Therefore KTIME_MAX is
> pushed as its next expiry and its own event kept as "ignore". As a result
> tmigr_update_events() ignores T1 and CPU 0 goes to idle with T1
> unhandled.
> 
> This isn't proper to single level hierarchy though. A similar issue,
> although slightly different, may arise on multi-level:
> 
>                              [GRP1:0]
>                           migrator = GRP0:0
>                           active   = GRP0:0
>                           nextevt  = T0:0i, T0:1
>                           /              \
>                [GRP0:0]                  [GRP0:1]
>             migrator = 0              migrator = NONE
>             active   = 0              active   = NONE
>             nextevt  = T0i            nextevt  = T2
>             /         \                /         \
>            0 (T0i)     1 (T1)         2 (T2)      3
>          idle         idle            idle         idle
> 
> 0) CPU 0 is active thus its event is ignored (the letter 'i') and so are
> upper levels' events. CPU 1 is idle and has the timer T1 enqueued.
> CPU 2 also has a timer. The expiry order is T0 (ignored) < T1 < T2
> 
>                              [GRP1:0]
>                           migrator = GRP0:0
>                           active   = GRP0:0
>                           nextevt  = T0:0i, T0:1
>                           /              \
>                [GRP0:0]                  [GRP0:1]
>             migrator = NONE           migrator = NONE
>             active   = NONE           active   = NONE
>             nextevt  = T0i            nextevt  = T2
>             /         \                /         \
>            0 (T0i)     1 (T1)         2 (T2)      3
>          idle         idle            idle         idle
> 
> 1) CPU 0 goes idle without global event queued. Therefore KTIME_MAX is
> pushed as its next expiry and its own event kept as "ignore". As a result
> tmigr_update_events() ignores T1. The change only propagated up to 1st
> level so far.
> 
>                              [GRP1:0]
>                           migrator = NONE
>                           active   = NONE
>                           nextevt  = T0:1
>                           /              \
>                [GRP0:0]                  [GRP0:1]
>             migrator = NONE           migrator = NONE
>             active   = NONE           active   = NONE
>             nextevt  = T0i            nextevt  = T2
>             /         \                /         \
>            0 (T0i)     1 (T1)         2 (T2)      3
>          idle         idle            idle         idle
> 
> 2) The change now propagates up to the top. tmigr_update_events() finds
> that the child event is ignored and thus removes it. The top level next
> event is now T2 which is returned to CPU 0 as its next effective expiry
> to take account for as the global idle migrator. However T1 has been
> ignored along the way, leaving it unhandled.
> 
> Fix those issues with removing the buggy related early return. Ignored
> child events must not prevent from evaluating the other events within
> the same group.
> 
> Reported-by: Boqun Feng <boqun.feng@gmail.com>
> Reported-by: Florian Fainelli <f.fainelli@gmail.com>

Gave it a good 20 cold boots and suspend to DRAM cycles and none of 
those triggered the reported behavior:

Reported-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>

Thanks for the quick fix Frederic!
-- 
Florian

  parent reply	other threads:[~2024-03-15 13:45 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08 17:15 [GIT PULL] RCU changes for v6.9 Boqun Feng
2024-03-11 19:43 ` pr-tracker-bot
2024-03-12 20:32 ` Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9] Florian Fainelli
2024-03-12 21:01   ` Frederic Weisbecker
2024-03-12 21:15     ` Paul E. McKenney
2024-03-12 21:35       ` Florian Fainelli
2024-03-12 22:05     ` Florian Fainelli
2024-03-12 21:07   ` Boqun Feng
2024-03-12 21:34     ` Florian Fainelli
2024-03-12 21:44       ` Linus Torvalds
2024-03-12 23:48         ` Boqun Feng
2024-03-13 16:01           ` Joel Fernandes
2024-03-13 21:30             ` Florian Fainelli
2024-03-13 21:59               ` Russell King (Oracle)
2024-03-13 22:04                 ` Florian Fainelli
2024-03-13 22:49                   ` Russell King (Oracle)
2024-03-13 23:29                     ` Florian Fainelli
2024-03-14  1:15                       ` Linus Torvalds
2024-03-14  1:22                         ` Florian Fainelli
2024-03-13 22:52                   ` Frederic Weisbecker
2024-03-14  3:44                     ` Florian Fainelli
2024-03-14  5:12                       ` Boqun Feng
2024-03-14  6:33                         ` Boqun Feng
2024-03-14  9:32                           ` Thomas Gleixner
2024-03-14  9:11                       ` Thomas Gleixner
2024-03-14 10:41                       ` Frederic Weisbecker
2024-03-14 18:35                         ` Florian Fainelli
2024-03-14 18:51                           ` Boqun Feng
2024-03-14 19:09                             ` Florian Fainelli
2024-03-14 20:45                               ` Thomas Gleixner
2024-03-14 21:21                                 ` Thomas Gleixner
2024-03-14 21:53                                   ` Florian Fainelli
2024-03-14 22:51                                     ` Thomas Gleixner
2024-03-14 21:58                                   ` Thomas Gleixner
2024-03-14 22:05                                   ` Boqun Feng
2024-03-14 22:10                                     ` Boqun Feng
2024-03-15  1:14                                     ` [PATCH] timer/migration: Remove buggy early return on deactivation [was Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9]] Frederic Weisbecker
2024-03-15  1:20                                       ` Frederic Weisbecker
2024-03-15 13:44                                       ` Florian Fainelli [this message]
2024-03-16 19:06                                       ` [tip: timers/urgent] timer/migration: Remove buggy early return on deactivation tip-bot2 for Frederic Weisbecker
2024-03-26 16:41                                       ` [PATCH] timer/migration: Remove buggy early return on deactivation [was Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9]] Anna-Maria Behnsen
2024-03-26 17:18                                         ` Frederic Weisbecker
2024-04-04 16:50                                           ` [PATCH] timers/migration: Return early on deactivation Anna-Maria Behnsen
2024-04-04 22:19                                             ` Frederic Weisbecker
2024-04-05  8:53                                               ` [PATCH v2] " Anna-Maria Behnsen
2024-04-05  9:11                                                 ` [tip: timers/urgent] " tip-bot2 for Anna-Maria Behnsen
2024-03-14  9:03                 ` Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9] Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1c5227a6-6b22-46c5-9966-d35ac1c770af@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=anna-maria@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=boqun.feng@gmail.com \
    --cc=chenzhongjin@huawei.com \
    --cc=frederic@kernel.org \
    --cc=joel@joelfernandes.org \
    --cc=justin.chen@broadcom.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mingo@kernel.org \
    --cc=neeraj.upadhyay@amd.com \
    --cc=paulmck@kernel.org \
    --cc=qiang.zhang1211@gmail.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=urezki@gmail.com \
    --cc=yangjihong1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®