mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: "Joel Fernandes (Google)" <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org, neeraju@codeaurora.org,
	Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	rcu@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v2] rcu/tree: nocb: Avoid raising softirq when there are ready to execute CBs
Date: Wed, 7 Oct 2020 15:34:38 -0700	[thread overview]
Message-ID: <20201007223438.GU29330@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20201005021132.146534-1-joel@joelfernandes.org>

On Sun, Oct 04, 2020 at 10:11:32PM -0400, Joel Fernandes (Google) wrote:
> During testing, I see it is possible that rcu_pending() returns 1 when
> offloaded callbacks are ready to execute thus raising the RCU softirq.
> 
> However, softirq does not execute offloaded callbacks. They are executed in a
> kthread which is awakened independent of the softirq.
> 
> This commit therefore avoids raising the softirq in the first place. That's
> probably a good thing considering that the purpose of callback offloading is to
> reduce softirq activity.
> 
> Passed 30 minute tests of TREE01 through TREE09 each.
> 
> On TREE08, I notice that there is atmost 150us from when the softirq was
> NOT raised when ready cbs were present, to when the ready callbacks were
> invoked by the rcuop thread. This also further confirms that there is no
> need to raise the softirq for ready cbs in the first place.
> 
> Cc: neeraju@codeaurora.org
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>

Looks good, applied, thank you!  I reworked things a bit based on
previous patches and to more precisely capture why this patch does
not cause additional problems.  Please let me know if I messed
anything up.

							Thanx, Paul

------------------------------------------------------------------------

commit 33847a34a2d261354a79b4a24d9d37222e8ec888
Author: Joel Fernandes (Google) <joel@joelfernandes.org>
Date:   Wed Oct 7 13:50:36 2020 -0700

    rcu/tree: nocb: Avoid raising softirq for offloaded ready-to-execute CBs
    
    Testing showed that rcu_pending() can return 1 when offloaded callbacks
    are ready to execute.  This invokes RCU core processing, for example,
    by raising RCU_SOFTIRQ, eventually resulting in a call to rcu_core().
    However, rcu_core() explicitly avoids in any way manipulating offloaded
    callbacks, which are instead handled by the rcuog and rcuoc kthreads,
    which work independently of rcu_core().
    
    One exception to this independence is that rcu_core() invokes
    do_nocb_deferred_wakeup(), however, rcu_pending() also checks
    rcu_nocb_need_deferred_wakeup() in order to correctly handle this case,
    invoking rcu_core() when needed.
    
    This commit therefore avoids needlessly invoking RCU core processing
    by checking rcu_segcblist_ready_cbs() only on non-offloaded CPUs.
    This reduces overhead, for example, by reducing softirq activity.
    
    This change passed 30 minute tests of TREE01 through TREE09 each.
    
    On TREE08, there is at most 150us from the time that rcu_pending() chose
    not to invoke RCU core processing to the time when the ready callbacks
    were invoked by the rcuoc kthread.  This provides further evidence that
    there is no need to invoke rcu_core() for offloaded callbacks that are
    ready to invoke.
    
    Cc: Neeraj Upadhyay <neeraju@codeaurora.org>
    Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 85e3f29..bfd38f2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3716,7 +3716,8 @@ static int rcu_pending(int user)
 		return 1;
 
 	/* Does this CPU have callbacks ready to invoke? */
-	if (rcu_segcblist_ready_cbs(&rdp->cblist))
+	if (!rcu_segcblist_is_offloaded(&rdp->cblist) &&
+	    rcu_segcblist_ready_cbs(&rdp->cblist))
 		return 1;
 
 	/* Has RCU gone idle with this CPU needing another grace period? */

  parent reply	other threads:[~2020-10-07 22:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05  2:11 Joel Fernandes (Google)
2020-10-05 14:38 ` joel
2020-10-07 22:34 ` Paul E. McKenney [this message]
2020-10-07 23:13   ` Frederic Weisbecker
2020-10-07 23:17     ` Paul E. McKenney
2020-10-08  7:19   ` Neeraj Upadhyay
2020-10-08 18:36     ` 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=20201007223438.GU29330@paulmck-ThinkPad-P72 \
    --to=paulmck@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=neeraju@codeaurora.org \
    --cc=rcu@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®