linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Naresh Kamboju <naresh.kamboju@linaro.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	lkft-triage@lists.linaro.org,
	Peter Zijlstra <peterz@infradead.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: i386: rcu-torture: WARNING: at kernel/rcu/rcutorture.c:1169 rcu_torture_writer [rcutorture]
Date: Thu, 17 Dec 2020 16:18:52 +0530	[thread overview]
Message-ID: <CA+G9fYsqcSjzEfGerJ_bJJJ3e00Cnqe0zE9yjqfQQYM78UQgtg@mail.gmail.com> (raw)
In-Reply-To: <20201216160330.GG2657@paulmck-ThinkPad-P72>

Hi Paul,

Thanks for your inputs.

On Wed, 16 Dec 2020 at 21:33, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Wed, Dec 16, 2020 at 03:40:04PM +0530, Naresh Kamboju wrote:
> > Linux Kernel Functional Testing (LKFT) started running rcu-torture tests on
> > qemu_arm64, qemu_arm qemu_x86_64 and qemu_i386 from our CI build systems.
> >
> > The following warning(s) noticed on qemu_i386 while running rcu-torture test
> > on Linux mainline and Linux -next master branch. Since we do not have baseline
> > results i can not comment this as regression but when compared with
> > stable-rc 5.4 kernel this warning is new on mainline and next.
>
> The rcutorture testing "stutters", that is, it periodically intentionally
> drops the test load down to zero for a few seconds.  The expectation is
> that with no load, rcutorture will have no trouble finishing any needed
> grace periods within that zero-load period.  If at the end of the stutter
> period, RCU work remains undone, then this warning is emitted.
>
> This warning can be a false positive in the following situations:
>
> 1.      The system on which you are running rcutorture is under
>         additional heavy load.

The DUT is running the test - rcutorture - only.

> 2.      You are running multiple guest OSes, each of which is running
>         rcutorture, and vCPUs from each of the guest OSes ends up
>         sharing a core with a vCPU from one of the other guests.  This
>         can cause the zero-load period to not be so unloaded.
>
> 3.      You built rcutorture into your kernel, so that rcutorture starts
>         immediately at boot time (CONFIG_RCU_TORTURE_TEST=y).  If your
>         boot takes long enough, rcutorture can massively overload the
>         single boot CPU, which can in turn result in this warning.

The test was built as a module.
CONFIG_RCU_TORTURE_TEST=m

>
> If you are in situation #1, I suggest disabling stuttering using the
> rcutorture.stutter=0 kernel boot parameter.
>
> If you are in situation #2, I suggest binding the guest-OS vCPUs
> to avoid them sharing cores with each other.
>
> If you are in situation #3, I have patches that I expect to submit
> upstream in the v5.12 merge window that can help.  Hey, they work for me!
> If you would like to test them before then, please let me know.
>
> If something else is going on, please let me know what it is so that
> I can fix it one way or another.

We were running on qemu_i386 today. I have tested on real hardware
and the reported problem has been reproduced.

> This warning has been present for quite some time, but I continually
> make rcutorture more aggressive, and this could well be part of the
> fallout of additional rcutorture aggression.
>
> And either way, thank you for trying out rcutorture!

We are happy to test :)

- Naresh

  reply	other threads:[~2020-12-17 10:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16 10:10 i386: rcu-torture: WARNING: at kernel/rcu/rcutorture.c:1169 rcu_torture_writer [rcutorture] Naresh Kamboju
2020-12-16 16:03 ` Paul E. McKenney
2020-12-17 10:48   ` Naresh Kamboju [this message]
2020-12-17 15:24     ` Paul E. McKenney
2020-12-17 17:16       ` Naresh Kamboju

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=CA+G9fYsqcSjzEfGerJ_bJJJ3e00Cnqe0zE9yjqfQQYM78UQgtg@mail.gmail.com \
    --to=naresh.kamboju@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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).