All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
To: lkp@lists.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>

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]

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


  reply	other threads:[~2018-06-19  2:37 UTC|newest]

Thread overview: 15+ 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  6:57     ` kernel test robot
2018-06-13  7:29     ` Joel Fernandes
2018-06-18 16:56       ` Paul E. McKenney
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:08             ` Paul E. McKenney
2018-06-19  1:36             ` Joel Fernandes
2018-06-19  1:36               ` Joel Fernandes
2018-06-19  2:38               ` Paul E. McKenney [this message]
2018-06-19  2:38                 ` Paul E. McKenney
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.