All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: bigeasy@linutronix.de
Cc: linux-kernel@vger.kernel.org
Subject: Review of RCU-related patches in -rt
Date: Tue, 28 May 2019 13:50:30 -0700	[thread overview]
Message-ID: <20190528205030.GA27149@linux.ibm.com> (raw)

Hello, Sebastian,

Finally getting around to taking another look:

c7e07056a108 EXP rcu: skip the workqueue path on RT

	This one makes sense given the later commit setting the
	rcu_normal_after_boot kernel parameter.  Otherwise, it is
	slowing down expedited grace periods for no reason.  But
	should the check also include rcu_normal_after_boot and
	rcu_normal?  For example:

		if ((IS_ENABLED(CONFIG_PREEMPT_RT_FULL) &&
		     (rcu_normal || rcu_normal_after_boot) ||
		    !READ_ONCE(rcu_par_gp_wq) ||
		    rcu_scheduler_active != RCU_SCHEDULER_RUNNING ||
		    rcu_is_last_leaf_node(rnp)) {

	Alternatively, one approach would be to take the kernel
	parameters out in -rt:

		static int rcu_normal_after_boot = IS_ENABLED(CONFIG_PREEMPT_RT_FULL);
		#ifndef CONFIG_PREEMPT_RT_FULL
		module_param(rcu_normal_after_boot, int, 0);
		#endif

	And similar for rcu_normal and rcu_expedited.

	Or is there some reason to allow run-time expedited grace
	periods in CONFIG_PREEMPT_RT_FULL=y kernels?

d1f52391bd8a rcu: Disable RCU_FAST_NO_HZ on RT

	Looks good.  More complexity could be added if too many people
	get themselves in trouble via "select RCU_FAST_NO_HZ".

42b346870326 rcu: make RCU_BOOST default on RT

	To avoid complaints about this showing up when people don't
	expected, could you please instead "select RCU_BOOST" in
	the Kconfig definition of PREEMPT_RT_FULL?

	Or do people really want to be able to disable boosting?

457c1b0d9c0e sched: Do not account rcu_preempt_depth on RT in might_sleep()

	The idea behind this one is to avoid false-positive complaints
	about -rt's sleeping spinlocks, correct?

7ee13e640b01 rbtree: don't include the rcu header
c9b0c9b87081 rtmutex: annotate sleeping lock context

	No specific comments.

7912d002ebf9 rcu: Eliminate softirq processing from rcutree

	This hasn't caused any problems in -rcu from what I can see.
	I am therefore planning to submit the -rcu variant of this to
	mainline during the next merge window.

f06d34ebdbbb srcu: Remove srcu_queue_delayed_work_on()

	Looks plausible.  I will check more carefully for mainline.

aeb04e894cc9 srcu: replace local_irqsave() with a locallock
e48989b033ad irqwork: push most work into softirq context

	These look to still be -rt only.

							Thanx, Paul


             reply	other threads:[~2019-05-28 20:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 20:50 Paul E. McKenney [this message]
2019-06-07 16:08 ` Review of RCU-related patches in -rt Sebastian Andrzej Siewior
2019-06-20 22:32   ` 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=20190528205030.GA27149@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.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.