public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.ibm.com>,
	josh@joshtriplett.org, rostedt@goodmis.org,
	mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com
Subject: dyntick-idle CPU and node's qsmask
Date: Sat, 10 Nov 2018 13:46:59 -0800	[thread overview]
Message-ID: <20181110214659.GA96924@google.com> (raw)

Hi Paul and everyone,

I was tracing/studying the RCU code today in paul/dev branch and noticed that
for dyntick-idle CPUs, the RCU GP thread is clearing the rnp->qsmask
corresponding to the leaf node for the idle CPU, and reporting a QS on their
behalf.

rcu_sched-10    [003]    40.008039: rcu_fqs:              rcu_sched 792 0 dti
rcu_sched-10    [003]    40.008039: rcu_fqs:              rcu_sched 801 2 dti
rcu_sched-10    [003]    40.008041: rcu_quiescent_state_report: rcu_sched 805 5>0 0 0 3 0

That's all good but I was wondering if we can do better for the idle CPUs if
we can some how not set the qsmask of the node in the first place. Then no
reporting would be needed of quiescent state is needed for idle CPUs right?
And we would also not need to acquire the rnp lock I think.

At least for a single node tree RCU system, it seems that would avoid needing
to acquire the lock without complications. Anyway let me know your thoughts
and happy to discuss this at the hallways of the LPC as well for folks
attending :)

thanks,

- Joel

             reply	other threads:[~2018-11-10 21:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-10 21:46 Joel Fernandes [this message]
2018-11-10 23:04 ` dyntick-idle CPU and node's qsmask Paul E. McKenney
2018-11-11  3:09   ` Joel Fernandes
2018-11-11  4:22     ` Paul E. McKenney
2018-11-11 18:09       ` Joel Fernandes
2018-11-11 18:36         ` Paul E. McKenney
2018-11-11 21:04           ` Joel Fernandes
2018-11-20 20:42           ` Joel Fernandes
2018-11-20 22:28             ` Paul E. McKenney
2018-11-20 22:34               ` Paul E. McKenney
2018-11-21  2:06               ` Joel Fernandes
2018-11-21  2:41                 ` Paul E. McKenney
2018-11-21  4:37                   ` Joel Fernandes
2018-11-21 14:39                     ` 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=20181110214659.GA96924@google.com \
    --to=joel@joelfernandes.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.ibm.com \
    --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