All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
	linux-rt-users@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/2] rcutorture: Nudge ksoftirqd priority for RCU boost testing
Date: Tue, 3 Aug 2021 16:42:31 -0700	[thread overview]
Message-ID: <20210803234231.GW4397@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20210803225437.3612591-3-valentin.schneider@arm.com>

On Tue, Aug 03, 2021 at 11:54:37PM +0100, Valentin Schneider wrote:
> As pointed out by commit 5e59fba573e6 ("rcutorture: Fix testing of RCU
> priority boosting"), timer expiry needs to run at a priority higher than
> that of the rcu_torture_boost threads (FIFO1) for RCU boost testing to
> function. If that's not the case, the rcu_torture_boost threads will
> prevent the wakeup of the RCU grace-period kthread, which means no boosting
> will be initiated.
> 
> Instead of setting this up manually, check the priority of ksoftirqd before
> starting the RCU boost test and nudge if required.
> 
> Note that this does not attempt to save and restore the scheduler
> parameters of ksoftirqd.
> 
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> ---
>  kernel/rcu/rcutorture.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 680f66b65f14..3dd5fa75f469 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -948,12 +948,26 @@ static int rcu_torture_boost(void *arg)
>  	unsigned long endtime;
>  	unsigned long oldstarttime;
>  	struct rcu_boost_inflight rbi = { .inflight = 0 };
> +	struct task_struct *ksoftirqd = this_cpu_ksoftirqd();
>  
>  	VERBOSE_TOROUT_STRING("rcu_torture_boost started");
>  
>  	/* Set real-time priority. */
>  	sched_set_fifo_low(current);
>  
> +	/*
> +	 * Boost testing requires TIMER_SOFTIRQ to run at a higher priority
> +	 * than the CPU-hogging torture kthreads, otherwise said threads
> +	 * will never let timer expiry for the RCU GP kthread happen, which will
> +	 * prevent any boosting.
> +	 */
> +	if (current->normal_prio < ksoftirqd->normal_prio) {

Would it make sense to add IS_ENABLED(CONFIG_PREEMPT_RT) to the above
condition?

							Thanx, Paul

> +		struct sched_param sp = { .sched_priority = 2 };
> +
> +		pr_alert("%s(): Adjusting %s priority\n", __func__, ksoftirqd->comm);
> +		sched_setscheduler_nocheck(ksoftirqd, SCHED_FIFO, &sp);
> +	}
> +
>  	init_rcu_head_on_stack(&rbi.rcu);
>  	/* Each pass through the following loop does one boost-test cycle. */
>  	do {
> -- 
> 2.25.1
> 

  reply	other threads:[~2021-08-03 23:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03 22:54 [PATCH 0/2] rcutorture: Some PREEMPT_RT fixlets Valentin Schneider
2021-08-03 22:54 ` [PATCH 1/2] rcutorture: Don't disable softirqs with preemption disabled when PREEMPT_RT Valentin Schneider
2021-08-03 23:43   ` Paul E. McKenney
2021-08-04 10:17     ` Valentin Schneider
2021-08-04 22:37       ` Paul E. McKenney
2021-08-03 22:54 ` [PATCH 2/2] rcutorture: Nudge ksoftirqd priority for RCU boost testing Valentin Schneider
2021-08-03 23:42   ` Paul E. McKenney [this message]
2021-08-04 10:18     ` Valentin Schneider
2021-08-04 22:53       ` Paul E. McKenney
2021-08-05 11:51         ` Valentin Schneider
2021-08-05 16:10           ` 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=20210803234231.GW4397@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=bristot@redhat.com \
    --cc=dave@stgolabs.net \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.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 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.