From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Joel Fernandes <joel@joelfernandes.org> Cc: kernel test robot <xiaolong.ye@intel.com>, Joel Fernandes <joelaf@google.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 09:56:46 -0700 [thread overview] Message-ID: <20180618165646.GA3593@linux.vnet.ibm.com> (raw) In-Reply-To: <20180613072948.GA142000@joelaf.mtv.corp.google.com> On Wed, Jun 13, 2018 at 12:29:48AM -0700, Joel Fernandes wrote: > (I'm actually not working this week, but still thought of replying :)) > > On Wed, Jun 13, 2018 at 02:57:11PM +0800, kernel test robot wrote: > > > > FYI, we noticed the following commit (built with gcc-4.9): > > > > commit: 46e26223e39c64763e321f229e324be15179c505 ("rcutorture: Make boost test more robust") > > url: https://github.com/0day-ci/linux/commits/Joel-Fernandes/rcutorture-Disable-RT-throttling-for-boost-tests/20180611-074731 > > base: https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git rcu/next > > > > in testcase: trinity > > with following parameters: > > > > runtime: 300s > > > > test-description: Trinity is a linux system call fuzz tester. > > test-url: http://codemonkey.org.uk/projects/trinity/ > > I'll try to reproduce this, but it could be because after this patch, the > boost test is actually working. Quite possibly. ;-) > 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? 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 09:56:46 -0700 [thread overview] Message-ID: <20180618165646.GA3593@linux.vnet.ibm.com> (raw) In-Reply-To: <20180613072948.GA142000@joelaf.mtv.corp.google.com> [-- Attachment #1: Type: text/plain, Size: 1889 bytes --] On Wed, Jun 13, 2018 at 12:29:48AM -0700, Joel Fernandes wrote: > (I'm actually not working this week, but still thought of replying :)) > > On Wed, Jun 13, 2018 at 02:57:11PM +0800, kernel test robot wrote: > > > > FYI, we noticed the following commit (built with gcc-4.9): > > > > commit: 46e26223e39c64763e321f229e324be15179c505 ("rcutorture: Make boost test more robust") > > url: https://github.com/0day-ci/linux/commits/Joel-Fernandes/rcutorture-Disable-RT-throttling-for-boost-tests/20180611-074731 > > base: https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git rcu/next > > > > in testcase: trinity > > with following parameters: > > > > runtime: 300s > > > > test-description: Trinity is a linux system call fuzz tester. > > test-url: http://codemonkey.org.uk/projects/trinity/ > > I'll try to reproduce this, but it could be because after this patch, the > boost test is actually working. Quite possibly. ;-) > 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? Thanx, Paul
next prev parent reply other threads:[~2018-06-18 16:55 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 [this message] 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 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=20180618165646.GA3593@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: linkBe 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.