All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: KarimAllah Ahmed <karahmed@amazon.de>
Cc: linux-kernel@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>
Subject: Re: [PATCH] rcu: Benefit from expedited grace period in __wait_rcu_gp
Date: Fri, 19 Oct 2018 05:31:06 -0700	[thread overview]
Message-ID: <20181019123106.GX2674@linux.ibm.com> (raw)
In-Reply-To: <1539910145-24305-1-git-send-email-karahmed@amazon.de>

On Fri, Oct 19, 2018 at 02:49:05AM +0200, KarimAllah Ahmed wrote:
> When expedited grace-period is set, both synchronize_sched
> synchronize_rcu_bh can be optimized to have a significantly lower latency.
> 
> Improve wait_rcu_gp handling to also account for expedited grace-period.
> The downside is that wait_rcu_gp will not wait anymore for all RCU variants
> concurrently when an expedited grace-period is set, however, given the
> improved latency it does not really matter.
> 
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>

Cute!

Unfortunately, there are a few problems with this patch:

1.	I will be eliminating synchronize_rcu_mult() due to the fact that
	the upcoming RCU flavor consolidation eliminates its sole caller.
	See 5fc9d4e000b1 ("rcu: Eliminate synchronize_rcu_mult()")
	in my -rcu tree.  This would of course also eliminate the effects
	of this patch.

2.	The real-time guys' users are not going to be at all happy
	with the IPIs resulting from the _expedited() API members.
	Yes, they can boot with rcupdate.rcu_normal=1, but they don't
	always need that big a hammer, and use of this kernel parameter
	can slow down boot, hibernation, suspend, network configuration,
	and much else besides.	We therefore don't want them to have to
	use rcupdate.rcu_normal=1 unless absolutely necessary.

3.	If the real-time guys' users were to have booted with
	rcupdate.rcu_normal=1, then synchronize_sched_expedited()
	would invoke _synchronize_rcu_expedited, which would invoke
	wait_rcu_gp(), which would invoke _wait_rcu_gp() which would
	invoke __wait_rcu_gp(), which, given your patch, would in turn
	invoke synchronize_sched_expedited().  This situation could
	well prevent their systems from meeting their response-time
	requirements.

So I cannot accept this patch nor for that matter any similar patch.

But what were you really trying to get done here?  If you were thinking
of adding another synchronize_rcu_mult(), the flavor consolidation will
make that unnecessary in most cases.  If you are trying to speed up
CPU-hotplug operations, I suggest using the rcu_expedited sysctl variable
when taking a CPU offline.  If something else, please let me know what
it is so that we can work out how the problem might best be solved.

							Thanx, Paul

> ---
>  kernel/rcu/update.c | 34 ++++++++++++++++++++++++++++------
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 68fa19a..44b8817 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -392,13 +392,27 @@ void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t *crcu_array,
>  			might_sleep();
>  			continue;
>  		}
> -		init_rcu_head_on_stack(&rs_array[i].head);
> -		init_completion(&rs_array[i].completion);
> +
>  		for (j = 0; j < i; j++)
>  			if (crcu_array[j] == crcu_array[i])
>  				break;
> -		if (j == i)
> -			(crcu_array[i])(&rs_array[i].head, wakeme_after_rcu);
> +		if (j != i)
> +			continue;
> +
> +		if ((crcu_array[i] == call_rcu_sched ||
> +		     crcu_array[i] == call_rcu_bh)
> +		    && rcu_gp_is_expedited()) {
> +			if (crcu_array[i] == call_rcu_sched)
> +				synchronize_sched_expedited();
> +			else
> +				synchronize_rcu_bh_expedited();
> +
> +			continue;
> +		}
> +
> +		init_rcu_head_on_stack(&rs_array[i].head);
> +		init_completion(&rs_array[i].completion);
> +		(crcu_array[i])(&rs_array[i].head, wakeme_after_rcu);
>  	}
> 
>  	/* Wait for all callbacks to be invoked. */
> @@ -407,11 +421,19 @@ void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t *crcu_array,
>  		    (crcu_array[i] == call_rcu ||
>  		     crcu_array[i] == call_rcu_bh))
>  			continue;
> +
> +		if ((crcu_array[i] == call_rcu_sched ||
> +		     crcu_array[i] == call_rcu_bh)
> +		    && rcu_gp_is_expedited())
> +			continue;
> +
>  		for (j = 0; j < i; j++)
>  			if (crcu_array[j] == crcu_array[i])
>  				break;
> -		if (j == i)
> -			wait_for_completion(&rs_array[i].completion);
> +		if (j != i)
> +			continue;
> +
> +		wait_for_completion(&rs_array[i].completion);
>  		destroy_rcu_head_on_stack(&rs_array[i].head);
>  	}
>  }
> -- 
> 2.7.4
> 


  reply	other threads:[~2018-10-19 12:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19  0:49 [PATCH] rcu: Benefit from expedited grace period in __wait_rcu_gp KarimAllah Ahmed
2018-10-19 12:31 ` Paul E. McKenney [this message]
2018-10-19 19:45   ` Raslan, KarimAllah
2018-10-19 20:21     ` Paul E. McKenney
2018-10-23 15:13       ` Raslan, KarimAllah
2018-10-24 11:20         ` 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=20181019123106.GX2674@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=karahmed@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.