From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 1/2] rcu/tree: handle VM stoppage in stall detection
Date: Mon, 24 May 2021 10:56:44 +0900 [thread overview]
Message-ID: <YKsH3GrEoxcMf4j0@google.com> (raw)
In-Reply-To: <20210521213855.GA3437356@paulmck-ThinkPad-P17-Gen-1>
On (21/05/21 14:38), Paul E. McKenney wrote:
>
> And on that otherwise inexplicable refetch of the jiffies counter within
> check_cpu_stall(), the commit below makes it more effective.
>
> If check_cpu_stall() is delayed before or while printing the stall
> warning, we really want to wait the full time duration between the
> end of that stall warning and the start of the next one.
>
Nice improvement!
> Of course, if there is some way to learn whether printk() is overloaded,
> even more effective approaches could be taken.
There is no better to do this.
> commit b9c5dc2856c1538ccf2d09246df2b58bede72cca
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date: Fri May 21 14:23:03 2021 -0700
>
> rcu: Start timing stall repetitions after warning complete
>
> Systems with low-bandwidth consoles can have very large printk()
> latencies, and on such systems it makes no sense to have the next RCU CPU
> stall warning message start output before the prior message completed.
> This commit therefore sets the time of the next stall only after the
> prints have completed. While printing, the time of the next stall
> message is set to ULONG_MAX/2 jiffies into the future.
>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
FWIW,
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> index 05012a8081a1..ff239189a627 100644
> --- a/kernel/rcu/tree_stall.h
> +++ b/kernel/rcu/tree_stall.h
> @@ -648,6 +648,7 @@ static void print_cpu_stall(unsigned long gps)
>
> static void check_cpu_stall(struct rcu_data *rdp)
> {
> + bool didstall = false;
> unsigned long gs1;
> unsigned long gs2;
> unsigned long gps;
> @@ -693,7 +694,7 @@ static void check_cpu_stall(struct rcu_data *rdp)
> ULONG_CMP_GE(gps, js))
> return; /* No stall or GP completed since entering function. */
> rnp = rdp->mynode;
> - jn = jiffies + 3 * rcu_jiffies_till_stall_check() + 3;
> + jn = jiffies + ULONG_MAX / 2;
> if (rcu_gp_in_progress() &&
> (READ_ONCE(rnp->qsmask) & rdp->grpmask) &&
> cmpxchg(&rcu_state.jiffies_stall, js, jn) == js) {
> @@ -710,6 +711,7 @@ static void check_cpu_stall(struct rcu_data *rdp)
> print_cpu_stall(gps);
> if (READ_ONCE(rcu_cpu_stall_ftrace_dump))
> rcu_ftrace_dump(DUMP_ALL);
> + didstall = true;
>
> } else if (rcu_gp_in_progress() &&
> ULONG_CMP_GE(j, js + RCU_STALL_RAT_DELAY) &&
> @@ -727,6 +729,11 @@ static void check_cpu_stall(struct rcu_data *rdp)
> print_other_cpu_stall(gs2, gps);
> if (READ_ONCE(rcu_cpu_stall_ftrace_dump))
> rcu_ftrace_dump(DUMP_ALL);
> + didstall = true;
> + }
> + if (didstall && READ_ONCE(rcu_state.jiffies_stall) == jn) {
Can `rcu_state.jiffies_stall` change here?
> + jn = jiffies + 3 * rcu_jiffies_till_stall_check() + 3;
> + WRITE_ONCE(rcu_state.jiffies_stall, jn);
> }
> }
next prev parent reply other threads:[~2021-05-24 1:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 15:56 [PATCHv2 1/2] rcu/tree: handle VM stoppage in stall detection Sergey Senozhatsky
2021-05-21 15:56 ` [PATCH 2/2] rcu: do not disable gp stall detection in rcu_cpu_stall_reset() Sergey Senozhatsky
2021-05-21 18:01 ` [PATCHv2 1/2] rcu/tree: handle VM stoppage in stall detection Paul E. McKenney
2021-05-21 21:38 ` Paul E. McKenney
2021-05-24 1:56 ` Sergey Senozhatsky [this message]
2021-05-24 3:46 ` Paul E. McKenney
2021-05-24 4:00 ` Sergey Senozhatsky
2021-07-15 9:09 ` Sergey Senozhatsky
2021-07-15 13:32 ` Paul E. McKenney
2021-07-15 14:08 ` Sergey Senozhatsky
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=YKsH3GrEoxcMf4j0@google.com \
--to=senozhatsky@chromium.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=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;
as well as URLs for NNTP newsgroup(s).