All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: linux-rt-users@vger.kernel.org
Cc: tglx@linutronix.de, bigeasy@linutronix.de,
	anna-maria@linutronix.de, williams@redhat.com, mingo@kernel.org,
	rostedt@goodmis.org
Subject: RCU simplification and RT needs
Date: Mon, 5 Jun 2017 13:35:50 -0700	[thread overview]
Message-ID: <20170605203550.GA7126@linux.vnet.ibm.com> (raw)

Hello!

At Linus's request, I am simplifying the Linux-kernel RCU implementation,
which includes removing code that implements features and options that
are no longer needed.  This is not a half-hearted effort.  In fact,
I expect that my submission to the next merge window will be a net
removal of more than 2500 lines of code.

But wait, there is more!  ;-)

Although the following two features are not being axed in v4.13, they
will be in v4.14 unless someone makes a convincing case for them:

1.	The ability to build a CONFIG_RCU_NOCB_CPUS=y kernel without
	also specifying CONFIG_NO_HZ_FULL.

	Unless someone speaks for this configuration option,
	CONFIG_RCU_NOCB_CPUS will be slaved off of CONFIG_NO_HZ_FULL,
	and the rcu_nocbs= boot parameter will be dropped.  (RCU would
	instead use the nohz_full= boot parameter to determine which
	CPUs get their callbacks offloaded.)

2.	The ability to specify polling for callback-offloaded CPUs.  This
	means that the rcu_nocb_poll= boot parameter will be dropped,
	and the CPU doing call_rcu() would do explicit wakeups, when
	needed, to get the corresponding rcuo kthread on the job.

	I have no evidence that anyone has ever used this option, other
	than me running the occasional rcutorture test.

So, anyone need either of these?  If not, out they go!  ;-)

							Thanx, Paul


             reply	other threads:[~2017-06-05 20:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05 20:35 Paul E. McKenney [this message]
2017-06-06  6:15 ` AW: RCU simplification and RT needs eg Engleder Gerhard
2017-06-06  7:57 ` Daniel Bristot de Oliveira
2017-06-06 12:58   ` 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=20170605203550.GA7126@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=anna-maria@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.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.