From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754888AbcEBTa0 (ORCPT ); Mon, 2 May 2016 15:30:26 -0400 Received: from e17.ny.us.ibm.com ([129.33.205.207]:44271 "EHLO e17.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754709AbcEBTaR (ORCPT ); Mon, 2 May 2016 15:30:17 -0400 X-IBM-Helo: d01dlp03.pok.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 2 May 2016 12:30:16 -0700 From: "Paul E. McKenney" To: Josh Triplett Cc: Boqun Feng , linux-kernel@vger.kernel.org Subject: Re: [RFC rcu/next] torture: Stop onoff task if there is only one cpu Message-ID: <20160502193016.GH3512@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1462156200-4811-1-git-send-email-boqun.feng@gmail.com> <20160502171848.GB4512@x> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160502171848.GB4512@x> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16050219-0041-0000-0000-0000040905C7 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 02, 2016 at 10:18:49AM -0700, Josh Triplett wrote: > On Mon, May 02, 2016 at 10:30:00AM +0800, Boqun Feng wrote: > > If the whole system has only one cpu, that cpu won't be able to be > > offlined, so there is no need onoff task is stil running. > > > > Signed-off-by: Boqun Feng > > --- > > > > I hit something like the following while I was running rcutorture > > in a guest with only one vCPU: > > > > [ 31.197457] rcu-torture:torture_onoff task: offlining 0 > > [ 31.197508] rcu-torture:torture_onoff task: offline 0 failed: errno -16 > > > > I know this is an expected behavior, but think we could just stop > > the onoff task if there is only one cpu. > > I find it a little bit unfortunate that this kicks off a thread just to > immediately exit that thread, rather than never starting it in the first > place. However, it also seems like the most convenient solution here, > and I don't see much point in going out of the way to optimize this test > for uniprocessor systems. > > Reviewed-by: Josh Triplett Thank you both! Queued for testing and further review. Thanx, Paul > > kernel/torture.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/kernel/torture.c b/kernel/torture.c > > index fb39a06bbef5..a85b7d61d9dd 100644 > > --- a/kernel/torture.c > > +++ b/kernel/torture.c > > @@ -194,6 +194,12 @@ torture_onoff(void *arg) > > for_each_online_cpu(cpu) > > maxcpu = cpu; > > WARN_ON(maxcpu < 0); > > + > > + if (maxcpu == 0) { > > + VERBOSE_TOROUT_STRING("only one cpu is found, onoff is impossible"); > > + goto stop; > > + } > > + > > if (onoff_holdoff > 0) { > > VERBOSE_TOROUT_STRING("torture_onoff begin holdoff"); > > schedule_timeout_interruptible(onoff_holdoff); > > @@ -209,6 +215,8 @@ torture_onoff(void *arg) > > &sum_online, &min_online, &max_online); > > schedule_timeout_interruptible(onoff_interval); > > } > > + > > +stop: > > torture_kthread_stopping("torture_onoff"); > > return 0; > > } > > -- > > 2.8.0 > > >