mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: 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>,
	Suleiman Souhlal <suleiman@google.com>,
	rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu/tree: consider time a VM was suspended
Date: Thu, 20 May 2021 07:53:18 -0700	[thread overview]
Message-ID: <20210520145318.GJ4441@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <YKX/H0EwRRLM+cAa@google.com>

On Thu, May 20, 2021 at 03:18:07PM +0900, Sergey Senozhatsky wrote:
> On (21/05/18 16:15), Paul E. McKenney wrote:
> > 
> > In the shorter term...  PVCLOCK_GUEST_STOPPED is mostly for things like
> > guest migration and debugger breakpoints, correct?  Either way, I am
> > wondering if rcu_cpu_stall_reset() should take a lighter touch.  Right
> > now, it effectively disables all stalls for the current grace period.
> > Why not make it restart the stall timeout when the stoppage is detected?
> 
> rcu_cpu_stall_reset() is used in many other places, not sure if we can
> change its behaviour rcu_cpu_stall_reset().

There was some use case back in the day where they wanted an indefinite
suppression of RCU CPU stall warnings for the current grace period, but
all the current use cases look fine with restarting the stall timeout.

However, please see below.

> Maybe it'll be possible to just stop calling it from PV-clock and do
> something like this

This was in fact one of the things I was considering, at least until
I convinced myself that I needed to ask some questions.

One point of possibly unnecessary nervousness on my part is resetting
the start of the grace period, which might confuse diagnostics.

But how about something like this?

void rcu_cpu_stall_reset(void)
{
	WRITE_ONCE(rcu_state.jiffies_stall,
		   jiffies + rcu_jiffies_till_stall_check());
}

Would something like that work?

(One issue with this is if there has already been an RCU CPU stall
warning, in which case the timeout for repeat warnings is tripled.  But in
the current use cases, I don't see that this matters.  If it turns out to
matter, I would just add a flag to rcu_state saying whether the current
grace period had seen a stall, and use that to decide whether or not
to triple the timeout.)

							Thanx, Paul

> ---
> 
> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
> index eda37df016f0..2d2489eda8e6 100644
> --- a/arch/x86/kernel/pvclock.c
> +++ b/arch/x86/kernel/pvclock.c
> @@ -40,7 +40,7 @@ void pvclock_touch_watchdogs(void)
>  {
>  	touch_softlockup_watchdog_sync();
>  	clocksource_touch_watchdog();
> -	rcu_cpu_stall_reset();
> +	record_gp_stall_check_time();
>  	reset_hung_task_detector();
>  }
>  
> diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> index cb233c79f0bc..6b3165c7a2c3 100644
> --- a/kernel/rcu/tree_stall.h
> +++ b/kernel/rcu/tree_stall.h
> @@ -137,7 +137,7 @@ void rcu_cpu_stall_reset(void)
>  // Interaction with RCU grace periods
>  
>  /* Start of new grace period, so record stall time (and forcing times). */
> -static void record_gp_stall_check_time(void)
> +void record_gp_stall_check_time(void)
>  {
>  	unsigned long j = jiffies;
>  	unsigned long j1;

  reply	other threads:[~2021-05-20 14:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 10:27 Sergey Senozhatsky
2021-05-17 16:23 ` Paul E. McKenney
2021-05-18  1:41   ` Sergey Senozhatsky
2021-05-18 23:15     ` Paul E. McKenney
2021-05-20  5:50       ` Sergey Senozhatsky
2021-05-20 14:57         ` Paul E. McKenney
2021-05-20 22:34           ` Sergey Senozhatsky
2021-05-21  0:15             ` Paul E. McKenney
2021-05-20  6:18       ` Sergey Senozhatsky
2021-05-20 14:53         ` Paul E. McKenney [this message]
2021-05-20 22:24           ` Sergey Senozhatsky
2021-05-21  0:14             ` Paul E. McKenney
2021-05-21  6:42               ` Sergey Senozhatsky
2021-05-21 14:02                 ` Paul E. McKenney
2021-05-21  6:36 ` Sergey Senozhatsky
2021-05-21 14:01   ` Paul E. McKenney

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=20210520145318.GJ4441@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@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=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=suleiman@google.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®