From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: Byungchul Park <byungchul.park@lge.com>,
josh@joshtriplett.org, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@lge.com
Subject: Re: [PATCH] rcu: Make jiffies_till_sched_qs writable
Date: Fri, 12 Jul 2019 09:43:11 -0400 [thread overview]
Message-ID: <20190712134311.GE92297@google.com> (raw)
In-Reply-To: <20190712130242.GM26519@linux.ibm.com>
On Fri, Jul 12, 2019 at 06:02:42AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 12, 2019 at 08:51:16AM -0400, Joel Fernandes wrote:
> > On Fri, Jul 12, 2019 at 03:32:40PM +0900, Byungchul Park wrote:
> > > On Thu, Jul 11, 2019 at 03:58:39PM -0400, Joel Fernandes wrote:
> > > > Hmm, speaking of grace period durations, it seems to me the maximum grace
> > > > period ever is recorded in rcu_state.gp_max. However it is not read from
> > > > anywhere.
> > > >
> > > > Any idea why it was added but not used?
> > > >
> > > > I am interested in dumping this value just for fun, and seeing what I get.
> > > >
> > > > I wonder also it is useful to dump it in rcutorture/rcuperf to find any
> > > > issues, or even expose it in sys/proc fs to see what worst case grace periods
> > > > look like.
> > >
> > > Hi,
> > >
> > > commit ae91aa0adb14dc33114d566feca2f7cb7a96b8b7
> > > rcu: Remove debugfs tracing
> > >
> > > removed all debugfs tracing, gp_max also included.
> > >
> > > And you sounds great. And even looks not that hard to add it like,
> > >
> > > :)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index ad9dc86..86095ff 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -1658,8 +1658,10 @@ static void rcu_gp_cleanup(void)
> > > raw_spin_lock_irq_rcu_node(rnp);
> > > rcu_state.gp_end = jiffies;
> > > gp_duration = rcu_state.gp_end - rcu_state.gp_start;
> > > - if (gp_duration > rcu_state.gp_max)
> > > + if (gp_duration > rcu_state.gp_max) {
> > > rcu_state.gp_max = gp_duration;
> > > + trace_rcu_grace_period(something something);
> > > + }
> >
> > Yes, that makes sense. But I think it is much better off as a readable value
> > from a virtual fs. The drawback of tracing for this sort of thing are:
> > - Tracing will only catch it if tracing is on
> > - Tracing data can be lost if too many events, then no one has a clue what
> > the max gp time is.
> > - The data is already available in rcu_state::gp_max so copying it into the
> > trace buffer seems a bit pointless IMHO
> > - It is a lot easier on ones eyes to process a single counter than process
> > heaps of traces.
> >
> > I think a minimal set of RCU counters exposed to /proc or /sys should not
> > hurt and could do more good than not. The scheduler already does this for
> > scheduler statistics. I have seen Peter complain a lot about new tracepoints
> > but not much (or never) about new statistics.
> >
> > Tracing has its strengths but may not apply well here IMO. I think a counter
> > like this could be useful for tuning of things like the jiffies_*_sched_qs,
> > the stall timeouts and also any other RCU knobs. What do you think?
>
> Is this one of those cases where eBPF is the answer, regardless of
> the question? ;-)
It could be. Except that people who fancy busybox still could benefit from
the counter ;-)
And also, eBPF uses RCU itself heavily, so it would help if the debug related
counter itself didn't depend on it. ;-)
thanks,
- Joel
next prev parent reply other threads:[~2019-07-12 13:43 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 6:00 [PATCH] rcu: Make jiffies_till_sched_qs writable Byungchul Park
2019-07-08 12:50 ` Paul E. McKenney
2019-07-08 13:03 ` Joel Fernandes
2019-07-08 13:19 ` Paul E. McKenney
2019-07-08 14:15 ` Joel Fernandes
2019-07-09 6:05 ` Byungchul Park
2019-07-09 12:43 ` Paul E. McKenney
2019-07-09 5:58 ` Byungchul Park
2019-07-09 6:45 ` Byungchul Park
2019-07-09 12:41 ` Paul E. McKenney
2019-07-10 1:20 ` Byungchul Park
2019-07-11 12:30 ` Paul E. McKenney
2019-07-11 13:08 ` Joel Fernandes
2019-07-11 15:02 ` Paul E. McKenney
2019-07-11 16:48 ` Joel Fernandes
2019-07-11 19:58 ` Joel Fernandes
2019-07-12 6:32 ` Byungchul Park
2019-07-12 12:51 ` Joel Fernandes
2019-07-12 13:02 ` Paul E. McKenney
2019-07-12 13:43 ` Joel Fernandes [this message]
2019-07-12 14:53 ` Paul E. McKenney
2019-07-13 8:47 ` Byungchul Park
2019-07-13 14:20 ` Joel Fernandes
2019-07-13 15:13 ` Paul E. McKenney
2019-07-13 15:42 ` Joel Fernandes
2019-07-13 17:41 ` Paul E. McKenney
2019-07-14 13:39 ` Byungchul Park
2019-07-14 13:56 ` Paul E. McKenney
2019-07-15 17:39 ` Joel Fernandes
2019-07-15 20:09 ` Paul E. McKenney
2019-07-18 16:14 ` Joel Fernandes
2019-07-18 16:15 ` Joel Fernandes
2019-07-18 21:34 ` Paul E. McKenney
2019-07-19 0:48 ` Joel Fernandes
2019-07-19 0:54 ` Byungchul Park
2019-07-19 0:39 ` Byungchul Park
2019-07-19 0:52 ` Joel Fernandes
2019-07-19 1:10 ` Byungchul Park
2019-07-19 7:43 ` Paul E. McKenney
2019-07-19 9:57 ` Byungchul Park
2019-07-19 19:57 ` Paul E. McKenney
2019-07-19 20:33 ` Joel Fernandes
2019-07-23 11:05 ` Byungchul Park
2019-07-23 13:47 ` Paul E. McKenney
2019-07-23 16:54 ` Paul E. McKenney
2019-07-24 7:58 ` Byungchul Park
2019-07-24 7:59 ` Byungchul Park
2019-07-12 13:01 ` Paul E. McKenney
2019-07-12 13:40 ` Joel Fernandes
2019-07-12 6:00 ` Byungchul Park
2019-07-12 5:52 ` Byungchul Park
2019-07-12 5:48 ` Byungchul Park
2019-07-13 9:08 ` Byungchul Park
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=20190712134311.GE92297@google.com \
--to=joel@joelfernandes.org \
--cc=byungchul.park@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.ibm.com \
--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;
as well as URLs for NNTP newsgroup(s).