From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: <paulmck@kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Boqun Feng <boqun.feng@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>, <rcu@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] rcu: Delete a redundant check in rcu_check_gp_kthread_starvation()
Date: Tue, 11 Jul 2023 11:20:07 +0800 [thread overview]
Message-ID: <4c8e0ea4-9dee-7915-e2eb-206ba50b79f2@huawei.com> (raw)
In-Reply-To: <f36c93ac-b735-4771-a4b5-4be80c431593@paulmck-laptop>
On 2023/7/11 3:03, Paul E. McKenney wrote:
> On Wed, Jul 05, 2023 at 03:30:19PM +0800, Zhen Lei wrote:
>> The above condition "if (gpk)" already ensures that gp_kthread is created,
>> so the local variable 'cpu' cannot be negative here.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> kernel/rcu/tree_stall.h | 12 +++++-------
>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
>> index b10b8349bb2a48b..dcfaa3d5db2cbc7 100644
>> --- a/kernel/rcu/tree_stall.h
>> +++ b/kernel/rcu/tree_stall.h
>> @@ -537,13 +537,11 @@ static void rcu_check_gp_kthread_starvation(void)
>> pr_err("\tUnless %s kthread gets sufficient CPU time, OOM is now expected behavior.\n", rcu_state.name);
>> pr_err("RCU grace-period kthread stack dump:\n");
>> sched_show_task(gpk);
>> - if (cpu >= 0) {
>
> I am not quite this trusting of the relation between the relationship
> between the existence of the grace-period khread and its CPU number
> being in range. Let's please start with something like this:
>
> if (!WARN_ON_ONCE(cpu < 0)) {
>
> Please note that this is not just me. See for example the use of the
> cpumask_check() function, albeit the opposite concern.
git grep -wn "\->cpu" kernel/ include/
kernel/kthread.c:583: to_kthread(p)->cpu = cpu; //kthread_create_on_cpu()
kernel/sched/sched.h:2024: WRITE_ONCE(task_thread_info(p)->cpu, cpu); //__set_task_cpu()
include/linux/sched.h:2250: return READ_ONCE(task_thread_info(p)->cpu); //task_cpu()
git grep -wn "\.cpu" kernel/ include/ //There is no task related, the search result is omitted.
Therefore, there is only one path "set_task_cpu()-->__set_task_cpu()" that can dynamically
change the value of task_cpu(p). In fact, this guarantee has been made in set_task_cpu().
set_task_cpu
WARN_ON_ONCE(!cpu_online(new_cpu));
__set_task_cpu(p, new_cpu);
In addition, task_struct has member 'on_rq'. Therefore, when a task leaves the scheduling
queue, setting the member 'cpu' to an invalid value will be thankless.
Sorry, these two patches was posted too quickly, and I'm still regretting that I should have
attached this to the commit description these days.
>
>> - if (cpu_is_offline(cpu)) {
>> - pr_err("RCU GP kthread last ran on offline CPU %d.\n", cpu);
>> - } else {
>> - pr_err("Stack dump where RCU GP kthread last ran:\n");
>> - dump_cpu_task(cpu);
>> - }
>> + if (cpu_is_offline(cpu)) {
>> + pr_err("RCU GP kthread last ran on offline CPU %d.\n", cpu);
>> + } else {
>> + pr_err("Stack dump where RCU GP kthread last ran:\n");
>> + dump_cpu_task(cpu);
>> }
>> wake_up_process(gpk);
>> }
>> --
>> 2.25.1
>>
> .
>
--
Regards,
Zhen Lei
next prev parent reply other threads:[~2023-07-11 3:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 7:30 [PATCH 0/2] rcu: Don't dump the stalled CPU on where RCU GP kthread last ran twice Zhen Lei
2023-07-05 7:30 ` [PATCH 1/2] rcu: Delete a redundant check in rcu_check_gp_kthread_starvation() Zhen Lei
2023-07-10 19:03 ` Paul E. McKenney
2023-07-11 3:20 ` Leizhen (ThunderTown) [this message]
2023-07-11 16:48 ` Paul E. McKenney
2023-07-13 2:03 ` Leizhen (ThunderTown)
2023-07-05 7:30 ` [PATCH 2/2] rcu: Don't dump the stalled CPU on where RCU GP kthread last ran twice Zhen Lei
2023-07-05 8:17 ` Leizhen (ThunderTown)
2023-07-10 19:05 ` Paul E. McKenney
2023-07-10 19:55 ` Joel Fernandes
2023-07-10 20:32 ` Paul E. McKenney
2023-07-11 3:26 ` Leizhen (ThunderTown)
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=4c8e0ea4-9dee-7915-e2eb-206ba50b79f2@huawei.com \
--to=thunder.leizhen@huawei.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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