All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org, kernel-team@android.com,
	Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Byungchul Park <byungchul.park@lge.com>
Subject: Re: [PATCH 1/2] rcu: Assign higher priority to RCU threads if its rcutorture
Date: Tue, 19 Jun 2018 09:00:24 -0700	[thread overview]
Message-ID: <20180619160024.GI3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180619063421.GA221670@joelaf.mtv.corp.google.com>

On Mon, Jun 18, 2018 at 11:34:21PM -0700, Joel Fernandes wrote:
> On Mon, Jun 18, 2018 at 11:22:14PM -0700, Joel Fernandes wrote:
> > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > 
> > rcutorture boost tests fail even with CONFIG_RCU_BOOST set because
> > rcutorture's threads are equal priority to the default RCU kthreads (RT
> > class with priority of 1).
> 
> Sorry for the weird subject line, I meant "rcu: Assign higher prio if
> rcutorture is built into kernel". I have included the patch with the subject
> line fixed up below (if you prefer to take that instead).
> 
> Also one question, incase rcutorture is a module, we can't raise the priority
> of the kthreads because it would be too late to do at module load time. In
> this case, do you have any ideas on what we can do? I was thinking we can
> access the kernel command line from within rcutorture module and check if
> 'rcutree.kthread_prio' was passed. And if it is and isn't sufficiently high,
> then we avoid testing boost feature at all (and print a nice message telling
> the user about the issue).

I do like the idea of checking and printing the message in this case.

Another alternative would be to allow rcutree.kthread_prio to be changed
at runtime.  But one caution: rcutree.kthread_prio applies to a number
of kthreads, not just the boost kthreads, so this approach might have
some unwelcome side-effects.

> OTOH, we can just let rcutorture module loaders fail the test if you feel
> very few automation tests do the module loading way of rcutorture and so a
> boost test failure there is tolerable. For me, I will likely be running
> rcutorture only as a built-in so I am Ok with not special casing it within
> rcutorture.

I don't know of anyone using the module-loading approach.  Probably
someone somewhere does it from time to time, though.

							Thanx, Paul

> thanks!
> 
>  - Joel
> 
> -----8<---------
> 
> >From 8cb7c2ac98e510abac35fdf2419a3212a587095a Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> Date: Mon, 18 Jun 2018 15:13:10 -0700
> Subject: [PATCH 1/2] rcu: Assign higher prio if rcutorture is built into kernel
> 
> rcutorture boost tests fail even with CONFIG_RCU_BOOST set because
> rcutorture's threads are equal priority to the default RCU kthreads (RT
> class with priority of 1).
> 
> This patch checks if RCU torture is built into the kernel and if so,
> assigns a higher priority to the RCU threads. With this the rcutorture
> boost tests pass.
> 
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
>  kernel/rcu/tree.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index deb2508be923..a141d6314622 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -171,7 +171,7 @@ static void rcu_report_exp_rdp(struct rcu_state *rsp,
>  static void sync_sched_exp_online_cleanup(int cpu);
> 
>  /* rcuc/rcub kthread realtime priority */
> -static int kthread_prio = IS_ENABLED(CONFIG_RCU_BOOST) ? 1 : 0;
> +static int kthread_prio;
>  module_param(kthread_prio, int, 0644);
> 
>  /* Delay in jiffies for grace-period initialization delays, debug only. */
> @@ -3884,12 +3884,16 @@ static int __init rcu_spawn_gp_kthread(void)
>  	struct task_struct *t;
> 
>  	/* Force priority into range. */
> -	if (IS_ENABLED(CONFIG_RCU_BOOST) && kthread_prio < 1)
> +	if (IS_ENABLED(CONFIG_RCU_BOOST) && kthread_prio < 2
> +	    && IS_BUILTIN(CONFIG_RCU_TORTURE_TEST))
> +		kthread_prio = 2;
> +	else if (IS_ENABLED(CONFIG_RCU_BOOST) && kthread_prio < 1)
>  		kthread_prio = 1;
>  	else if (kthread_prio < 0)
>  		kthread_prio = 0;
>  	else if (kthread_prio > 99)
>  		kthread_prio = 99;
> +
>  	if (kthread_prio != kthread_prio_in)
>  		pr_alert("rcu_spawn_gp_kthread(): Limited prio to %d from %d\n",
>  			 kthread_prio, kthread_prio_in);
> -- 
> 2.18.0.rc1.244.gcf134e6275-goog
> 


  reply	other threads:[~2018-06-19 15:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19  6:22 [PATCH 1/2] rcu: Assign higher priority to RCU threads if its rcutorture Joel Fernandes
2018-06-19  6:22 ` [PATCH 2/2] rcutorture: Fix rcu_barrier successes counter Joel Fernandes
2018-06-19  7:31   ` Joel Fernandes
2018-06-19 13:12     ` Steven Rostedt
2018-06-19 15:41       ` Paul E. McKenney
2018-06-19 22:16         ` Joel Fernandes
2018-06-19  6:34 ` [PATCH 1/2] rcu: Assign higher priority to RCU threads if its rcutorture Joel Fernandes
2018-06-19 16:00   ` Paul E. McKenney [this message]
2018-06-19 22:19     ` Joel Fernandes

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=20180619160024.GI3593@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@android.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.