[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZJixj2RJrp8A8POz@localhost.localdomain>
Date: Sun, 25 Jun 2023 23:28:47 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Cruz Zhao <CruzZhao@...ux.alibaba.com>
Cc: gregkh@...uxfoundation.org, jirislaby@...nel.org, mingo@...hat.com,
peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, vschneid@...hat.com, paulmck@...nel.org,
quic_neeraju@...cinc.com, joel@...lfernandes.org,
josh@...htriplett.org, boqun.feng@...il.com,
mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
qiang1.zhang@...el.com, jstultz@...gle.com,
clingutla@...eaurora.org, nsaenzju@...hat.com, tglx@...utronix.de,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] sched/core: introduce sched_core_idle_cpu()
Le Sun, Jun 25, 2023 at 02:28:15AM +0800, Cruz Zhao a écrit :
> As core scheduling introduced, a new state of idle is defined as
> force idle, running idle task but nr_running greater than zero.
>
> If a cpu is in force idle state, idle_cpu() will return zero. This
> result makes sense in certain scenarios, e.g., load balance. but
> this will cause error in other scenarios, e.g., tick_irq_exit()
> will not change ts->idle_active back to 1 because idle_cpu() returns
> 0 when force idle.
>
> To solve this problem, we introduce sched_core_idle_cpu(), which
> returns 1 when force idle. We audit all users of idle_cpu(), and
> change idle_cpu() into sched_core_idle_cpu() in the following
> functions:
> - showacpu()
> - rcu_is_rcuc_kthread_starving()
> - tick_irq_exit()
>
> v1-->v2: replace idle_cpu() with sched_core_idle_cpu() in function
> showacpu() and rcu_is_rcuc_kthread_starving()
>
> Signed-off-by: Cruz Zhao <CruzZhao@...ux.alibaba.com>
> ---
> drivers/tty/sysrq.c | 2 +-
> include/linux/sched.h | 2 ++
> kernel/rcu/tree_stall.h | 2 +-
> kernel/sched/core.c | 13 +++++++++++++
> kernel/softirq.c | 2 +-
> 5 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> index b6e70c5cfa17..8a6586800385 100644
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -232,7 +232,7 @@ static void showacpu(void *dummy)
> unsigned long flags;
>
> /* Idle CPUs have no interesting backtrace. */
> - if (idle_cpu(smp_processor_id())) {
> + if (sched_core_idle_cpu(smp_processor_id())) {
> pr_info("CPU%d: backtrace skipped as idling\n", smp_processor_id());
Actually perhaps an idle injection's backtrace is worth dumping. I guess
it might accidentally produce lockups and it's worth knowing the source then.
Though I don't have a strong opinion on that...
> return;
> }
> diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> index b10b8349bb2a..6169faf30ecd 100644
> --- a/kernel/rcu/tree_stall.h
> +++ b/kernel/rcu/tree_stall.h
> @@ -418,7 +418,7 @@ static bool rcu_is_rcuc_kthread_starving(struct rcu_data *rdp, unsigned long *jp
> return false;
>
> cpu = task_cpu(rcuc);
> - if (cpu_is_offline(cpu) || idle_cpu(cpu))
> + if (cpu_is_offline(cpu) || sched_core_idle_cpu(cpu))
An idle injection could possibly starve the RCU boost kthread, and then it's
worth knowing about it. I would suggest keeping idle_cpu() here.
> return false;
>
> j = jiffies - READ_ONCE(rdp->rcuc_activity);
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index c8a6913c067d..98b98991ce45 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -630,7 +630,7 @@ static inline void tick_irq_exit(void)
> int cpu = smp_processor_id();
>
> /* Make sure that timer wheel updates are propagated */
> - if ((idle_cpu(cpu) && !need_resched()) || tick_nohz_full_cpu(cpu)) {
> + if ((sched_core_idle_cpu(cpu) && !need_resched()) || tick_nohz_full_cpu(cpu)) {
That one looks good.
Thanks!
Powered by blists - more mailing lists