From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joel Fernandes <joelaf@google.com>
Cc: Joel Fernandes <joel@joelfernandes.org>,
kernel test robot <xiaolong.ye@intel.com>,
linux-kernel@vger.kernel.org, kernel-team@android.com,
Josh Triplett <josh@joshtriplett.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
mingo@redhat.com, Steven Rostedt <rostedt@goodmis.org>,
tglx@linutronix.de, lkp@01.org
Subject: Re: [lkp-robot] [rcutorture] 46e26223e3: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_stats_print
Date: Mon, 18 Jun 2018 19:38:59 -0700 [thread overview]
Message-ID: <20180619023859.GE3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <2CDE3A5B-1AD3-4185-9E24-24D4075A9EA6@google.com>
On Mon, Jun 18, 2018 at 06:36:06PM -0700, Joel Fernandes wrote:
>
>
> On June 18, 2018 6:08:03 PM PDT, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >On Mon, Jun 18, 2018 at 03:26:47PM -0700, Joel Fernandes wrote:
> >> On Mon, Jun 18, 2018 at 09:56:46AM -0700, Paul E. McKenney wrote:
> >> > > The reason for the rcutorture test failure could be that the
> >default
> >> > > kthread_prio for the system's RCU threads is set to 1 (unless
> >overridden by
> >> > > rcutree.kthread_prio) which is also equal to the priority of the
> >rcutorture's
> >> > > boost threads. Due to this the rcutorture test could starve the
> >RCU threads
> >> > > as well and defeat the boosting mechanism. I was able to solve a
> >similar
> >> > > issue by just passing rcutree.kthread_prio of 50 on the kernel
> >command line.
> >> > >
> >> > > Paul, would it be ok if we changed the default kthread_prio to
> >something > 1
> >> > > so that rcutorture can test properly without needing to pass any
> >extra
> >> > > rcutree.* parameters?
> >> > >
> >> > > so something like this in kernel/rcu/tree.c ?
> >> > >
> >> > > static int kthread_prio = IS_ENABLED(CONFIG_RCU_BOOST) ? 2 : 0;
> >> >
> >> > Would it be possible to also condition this on rcutorture being
> >built
> >> > in? Or are they doing modprobes for rcutorture?
> >>
> >> They seem to be doing built-in rcutorture tests. But I believe the
> >same
> >> problem would occur even if you used modules? I believe the fact that
> >> rcutorture is a module or built-in wouldn't matter to the underlying
> >issue
> >> which is the RCU subsystems's threads are at too low of a priority
> >> (rcutree.kthread_prio = 1).
> >
> >Understood...
> >
> >> If you agree with changing the default priority, I have included a
> >patch
> >> below for rcu/dev.
> >
> >The problem is that without rcutorture, rcutree.kthread_prio=1 is a
> >legitimate choice, and changing the default globally could be breaking
> >someone. So it would be far better to up the priority only during
> >known
> >rcutorture testing.
>
> Oh I see what you're saying. I'll work on a patch along these lines
> then. Thanks!
Looking forward to seeing it!
Thanx, Paul
next prev parent reply other threads:[~2018-06-19 2:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-10 23:45 [PATCH 1/2] rcutorture: Disable RT throttling for boost tests Joel Fernandes
2018-06-10 23:45 ` [PATCH 2/2] rcutorture: Make boost test more robust Joel Fernandes
2018-06-13 6:57 ` [lkp-robot] [rcutorture] 46e26223e3: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_stats_print kernel test robot
2018-06-13 7:29 ` Joel Fernandes
2018-06-18 16:56 ` Paul E. McKenney
2018-06-18 22:26 ` Joel Fernandes
2018-06-19 1:08 ` Paul E. McKenney
2018-06-19 1:36 ` Joel Fernandes
2018-06-19 2:38 ` Paul E. McKenney [this message]
2018-06-11 12:56 ` [PATCH 1/2] rcutorture: Disable RT throttling for boost tests 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=20180619023859.GE3593@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=joelaf@google.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=xiaolong.ye@intel.com \
/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