public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: "Zhang, Qiang1" <qiang1.zhang@intel.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	"frederic@kernel.org" <frederic@kernel.org>,
	"quic_neeraju@quicinc.com" <quic_neeraju@quicinc.com>,
	"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] rcu: Remove impossible wakeup rcu GP kthread action from rcu_report_qs_rdp()
Date: Tue, 24 Jan 2023 17:10:21 +0000	[thread overview]
Message-ID: <Y9AQ/Yob7x/dif82@google.com> (raw)
In-Reply-To: <PH0PR11MB58803DFEDD61EE66AF49074EDACA9@PH0PR11MB5880.namprd11.prod.outlook.com>

On Sat, Jan 21, 2023 at 12:38:35AM +0000, Zhang, Qiang1 wrote:
[...]
> >If you are in an intermediate state, part way to a !nocb state — 
> >you may have missed a nocb-related accel and wake, correct? Why does that matter? 
> >Once we transition to a !nocb state, we do not do a post-qs-report accel+wake anyway
> 
> Should it be transition to a !nocb state, we do a post-qs-report accel+wake.
> 
> >as we clearly know from the discussion. So why do we need to do it if we missed it for
> >the intermediate stage? So, I am not fully sure yet what that needac is doing and why it is needed.
> 
> For de-offloading, when in the process of
> de-offloading(rcu_segcblist_completely_offloaded() return false), we're not
> doing bypass even though this rdp is offloaded
> state(rcu_rdp_is_offloaded(rdp) return true), at this time, the rcuog
> kthread probably won't accel+wakeup, so we do accel+wakeup in
> rcu_report_qs_rdp(), as you say why does that matter?  for !nocb state,
> we've always tried to accel+wakeup as much as possible(compared to nocb),
> let rcu callback be executed as soon as possible.
> 
> This is just my personal opinion, please correct me if I am wrong.

I think your opinion is correct. The acceleration after the QS reporting may
be needed for the case where we are part way between the offload and
de-offload state as in this state (which we could call limbo state), there
does not seem to be anywhere that acceleration is performed, and if this state
persists for a long period of time, then no other path can accelerate the CBs
thus likely starving them as Frederic mentioned..

thanks,

 - Joel


> Thanks
> Zqiang
> 
> 
> >
> >Do not get me wrong, stellar work here. But I suggest challenge the assumptions and the design, not always just the code that was already written :), apologies for any misplaced or noisy advice.
> >
> >Thanks!
> >
> > - Joel
> 
> 
> >    
> > Thanks
> > Zqiang
> > 
> >> 
> >> (I am out of office till Monday but will intermittently (maybe) check
> >> in, RCU is one of those things that daydreaming tends to lend itself
> >> to...)
> >> 
> >> - Joel

      reply	other threads:[~2023-01-24 17:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18  7:30 [PATCH v3] rcu: Remove impossible wakeup rcu GP kthread action from rcu_report_qs_rdp() Zqiang
2023-01-18 10:18 ` Frederic Weisbecker
2023-01-18 18:07 ` Paul E. McKenney
2023-01-18 23:30   ` Zhang, Qiang1
2023-01-20  3:14   ` Joel Fernandes
2023-01-20  3:17     ` Joel Fernandes
2023-01-20  4:09     ` Zhang, Qiang1
2023-01-20  4:40       ` Joel Fernandes
2023-01-20  8:19         ` Zhang, Qiang1
2023-01-20 13:27           ` Joel Fernandes
2023-01-20 20:33             ` Paul E. McKenney
2023-01-20 22:35               ` Frederic Weisbecker
2023-01-20 23:20                 ` Paul E. McKenney
2023-01-20 23:04             ` Frederic Weisbecker
2023-01-23 15:22               ` Joel Fernandes
2023-01-23 16:27                 ` Frederic Weisbecker
2023-01-23 20:54                   ` Joel Fernandes
2023-01-23 21:11                     ` Frederic Weisbecker
2023-01-24 16:58                       ` Joel Fernandes
2023-01-21  0:38             ` Zhang, Qiang1
2023-01-24 17:10               ` Joel Fernandes [this message]

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=Y9AQ/Yob7x/dif82@google.com \
    --to=joel@joelfernandes.org \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=qiang1.zhang@intel.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox