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
>
next prev parent 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 [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them 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 \
/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.