From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>
Subject: Re: [RFC PATCH 12/12] rcu: Nocb (de)activate through sysfs
Date: Wed, 23 Sep 2020 21:00:50 +0200 [thread overview]
Message-ID: <20200923190050.GA1026@lenoir> (raw)
In-Reply-To: <20200923154716.GP29330@paulmck-ThinkPad-P72>
On Wed, Sep 23, 2020 at 08:47:16AM -0700, Paul E. McKenney wrote:
> On Wed, Sep 23, 2020 at 05:27:46PM +0200, Frederic Weisbecker wrote:
> > On Mon, Sep 21, 2020 at 05:26:29PM -0700, Paul E. McKenney wrote:
> > > On Mon, Sep 21, 2020 at 02:43:51PM +0200, Frederic Weisbecker wrote:
> > > > Not for merge.
> > > >
> > > > Make nocb toggable for a given CPU using:
> > > > /sys/devices/system/cpu/cpu*/hotplug/nocb
> > > >
> > > > This is only intended for those who want to test this patchset. The real
> > > > interfaces will be cpuset/isolation and rcutorture.
> > >
> > > Excellent choice for testing in the near term!
> > >
> > > How does rcutorture fare with this series if an additional kthread toggles
> > > offloading on and off continually?
> >
> > So yeah that would be the plan: having something that randomly toggles
> > offloading from the RCU tests themselves. I'm not quite familiar with
> > rcutorture internals yet though.
>
> If you supply a function that selects a CPU and does the toggle, I
> can quickly and easily wire it into rcutorture. I of course have no
> objection to your learning to do this yourself, but the offer stands.
I gladly accept your proposal! This way I will integrate it in the set
and start testing.
The functions to call would be:
void rcu_nocb_cpu_offload(int cpu);
void rcu_nocb_cpu_deoffload(int cpu);
>
> > > All questions and concerns aside, excellent progress and nice work!!!
> >
> > Thanks! We are slowly making progress :)
>
> Better than quickly failing to make progress, to be sure! ;-)
;-)
Thanks a lot!
next prev parent reply other threads:[~2020-09-23 19:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 12:43 [RFC PATCH 00/12] rcu/nocb: De-offload and re-offload support v2 Frederic Weisbecker
2020-09-21 12:43 ` [RFC PATCH 01/12] rcu: Implement rcu_segcblist_is_offloaded() config dependent Frederic Weisbecker
2020-09-22 0:27 ` Paul E. McKenney
2020-09-22 21:43 ` Frederic Weisbecker
2020-09-22 23:11 ` Paul E. McKenney
2020-09-23 15:25 ` Frederic Weisbecker
2020-09-21 12:43 ` [RFC PATCH 02/12] rcu: Turn enabled/offload states into a common flag Frederic Weisbecker
2020-09-21 12:43 ` [RFC PATCH 03/12] rcu: Provide basic callback offloading state machine bits Frederic Weisbecker
2020-09-21 23:50 ` Paul E. McKenney
2020-09-21 12:43 ` [RFC PATCH 04/12] rcu: De-offloading CB kthread Frederic Weisbecker
2020-09-22 0:07 ` Paul E. McKenney
2020-09-21 12:43 ` [RFC PATCH 05/12] rcu: De-offloading GP kthread Frederic Weisbecker
2020-09-22 0:10 ` Paul E. McKenney
2020-09-23 15:31 ` Frederic Weisbecker
2020-09-23 15:48 ` Paul E. McKenney
2020-09-21 12:43 ` [RFC PATCH 06/12] rcu: Re-offload support Frederic Weisbecker
2020-09-21 12:43 ` [RFC PATCH 07/12] rcu: Shutdown nocb timer on de-offloading Frederic Weisbecker
2020-09-22 0:17 ` Paul E. McKenney
2020-09-23 15:29 ` Frederic Weisbecker
2020-09-23 15:47 ` Paul E. McKenney
2020-09-21 12:43 ` [RFC PATCH 08/12] rcu: Flush bypass before setting SEGCBLIST_SOFTIRQ_ONLY Frederic Weisbecker
2020-09-21 12:43 ` [RFC PATCH 09/12] rcu: Set SEGCBLIST_SOFTIRQ_ONLY at the very last stage of de-offloading Frederic Weisbecker
2020-09-21 12:43 ` [RFC PATCH 10/12] rcu: Process batch locally as long as offloading isn't complete Frederic Weisbecker
2020-09-22 0:22 ` Paul E. McKenney
2020-09-21 12:43 ` [RFC PATCH 11/12] rcu: Locally accelerate callbacks " Frederic Weisbecker
2020-09-22 0:24 ` Paul E. McKenney
2020-09-21 12:43 ` [RFC PATCH 12/12] rcu: Nocb (de)activate through sysfs Frederic Weisbecker
2020-09-22 0:26 ` Paul E. McKenney
2020-09-23 15:27 ` Frederic Weisbecker
2020-09-23 15:47 ` Paul E. McKenney
2020-09-23 19:00 ` Frederic Weisbecker [this message]
2020-09-24 0:38 ` 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=20200923190050.GA1026@lenoir \
--to=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--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.