LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Byungchul Park <byungchul.park@lge.com>
Cc: jiangshanlai@gmail.com, josh@joshtriplett.org,
	rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
	linux-kernel@vger.kernel.org, kernel-team@lge.com,
	joel@joelfernandes.org
Subject: Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them
Date: Tue, 29 May 2018 05:01:55 -0700	[thread overview]
Message-ID: <20180529120155.GC3803@linux.vnet.ibm.com> (raw)
In-Reply-To: <1527578616-5595-1-git-send-email-byungchul.park@lge.com>

On Tue, May 29, 2018 at 04:23:36PM +0900, Byungchul Park wrote:
> Hello Paul and folks,
> 
> I've thought the code should've been like the below since the range
> checking of jiffies_till_first_fqs and jiffies_till_next_fqs everytime
> in the loop of rcu_gp_kthread are unnecessary at all. However, it's ok
> even if you don't think it's worth doing it.

Nice!

> Secondly, I also think jiffies_till_first_fqs = 0 is meaningless so
> added checking and adjusting it as what's done on jiffies_till_next_fqs.
> Thought?

Actually, jiffies_till_first_fqs == 0 is very useful for cases where
at least one CPU is expected to be idle and grace-period latency is
important.  In this case, doing the first scan immediately gets the
dyntick-idle state recorded immediately, getting the idle CPUs out of
the way of the grace period immediately.

So why not do this scan as part of grace-period initialization?  Because
doing so consumes extra CPU and results in extra cache misses, which is
the opposite of what you want on a completely busy system, especially
one where the CPUs are context switching quickly.  Thus no scan during
grace-period initialization.

But I can see the desire to share code.

One approach would be to embed the kernel_params_ops structure inside
another structure containing the limits, then just have two structures.
Perhaps something like this already exists?  I don't see it right off,
but then again, I am not exactly an expert on module_param.

Thoughts?

							Thanx, Paul

> Thank you in advance.
> Byungchul
> 
> ----->8-----
> >From 67fecc15b44b2521de96de109782c04ce65afb85 Mon Sep 17 00:00:00 2001
> From: Byungchul Park <byungchul.park@lge.com>
> Date: Tue, 29 May 2018 15:49:26 +0900
> Subject: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them
> 
> Currently, the range of jiffies_till_first_fqs and jiffies_till_next_fqs
> are always checked and adjusted in the loop of rcu_gp_kthread on runtime.
> However, it would be better and enough to check them only on setting
> them, so remove unnecessary checking and adjusting in the loop.
> 
> Additionally, add adjusting jiffies_till_first_fqs so guaranteed to be
> greater than 0, which hasn't been done before.
> 
> Signed-off-by: Byungchul Park <byungchul.park@lge.com>
> ---
>  kernel/rcu/tree.c | 38 +++++++++++++++++++++++++-------------
>  1 file changed, 25 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 4e96761..4964237 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -518,8 +518,31 @@ void rcu_all_qs(void)
>  static ulong jiffies_till_next_fqs = ULONG_MAX;
>  static bool rcu_kick_kthreads;
> 
> -module_param(jiffies_till_first_fqs, ulong, 0644);
> -module_param(jiffies_till_next_fqs, ulong, 0644);
> +static int param_set_fqs_jiffies(const char *val, const struct kernel_param *kp)
> +{
> +	ulong tmp;
> +	int ret = kstrtoul(val, 0, &tmp);
> +
> +	if (ret < 0)
> +		return ret;
> +
> +	if (tmp > HZ)
> +		tmp = HZ;
> +	else if (tmp < 1)
> +		tmp = 1;
> +
> +	/* Prevent tearing */
> +	WRITE_ONCE(*(ulong *)kp->arg, tmp);
> +	return 0;
> +}
> +
> +static struct kernel_param_ops fqs_jiffies_ops = {
> +	.set = param_set_fqs_jiffies,
> +	.get = param_get_ulong,
> +};
> +
> +module_param_cb(jiffies_till_first_fqs, &fqs_jiffies_ops, &jiffies_till_first_fqs, 0644);
> +module_param_cb(jiffies_till_next_fqs, &fqs_jiffies_ops, &jiffies_till_next_fqs, 0644);
>  module_param(rcu_kick_kthreads, bool, 0644);
> 
>  /*
> @@ -2129,10 +2152,6 @@ static int __noreturn rcu_gp_kthread(void *arg)
>  		/* Handle quiescent-state forcing. */
>  		first_gp_fqs = true;
>  		j = jiffies_till_first_fqs;
> -		if (j > HZ) {
> -			j = HZ;
> -			jiffies_till_first_fqs = HZ;
> -		}
>  		ret = 0;
>  		for (;;) {
>  			if (!ret) {
> @@ -2167,13 +2186,6 @@ static int __noreturn rcu_gp_kthread(void *arg)
>  				WRITE_ONCE(rsp->gp_activity, jiffies);
>  				ret = 0; /* Force full wait till next FQS. */
>  				j = jiffies_till_next_fqs;
> -				if (j > HZ) {
> -					j = HZ;
> -					jiffies_till_next_fqs = HZ;
> -				} else if (j < 1) {
> -					j = 1;
> -					jiffies_till_next_fqs = 1;
> -				}
>  			} else {
>  				/* Deal with stray signal. */
>  				cond_resched_tasks_rcu_qs();
> -- 
> 1.9.1
> 

  reply	other threads:[~2018-05-29 12:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29  7:23 Byungchul Park
2018-05-29 12:01 ` Paul E. McKenney [this message]
2018-05-30 13:06   ` Byungchul Park
2018-05-30 13:49     ` Paul E. McKenney
2018-05-31  1:27       ` Byungchul Park
2018-05-31  2:18   ` Byungchul Park
2018-05-31  2:51     ` Byungchul Park
2018-05-31 11:17       ` Paul E. McKenney
2018-06-01  1:42         ` Byungchul Park

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=20180529120155.GC3803@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=byungchul.park@lge.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=kernel-team@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=rostedt@goodmis.org \
    --subject='Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them' \
    /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

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).