Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 13 May 2019 11:37:14 -0400
From:   Joel Fernandes <joel@joelfernandes.org>
To:     "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc:     Andrea Parri <andrea.parri@amarulasolutions.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: Question about sched_setaffinity()
Message-ID: <20190513153714.GA40957@google.com>
References: <20190501202713.GY3923@linux.ibm.com>
 <20190507221613.GA11057@linux.ibm.com>
 <20190509173654.GA23530@linux.ibm.com>
 <20190509193625.GA12455@linux.ibm.com>
 <20190510120819.GR2589@hirez.programming.kicks-ass.net>
 <20190510230742.GY3923@linux.ibm.com>
 <20190511214520.GA3251@andrea>
 <20190512003915.GD3923@linux.ibm.com>
 <20190512010539.GA8167@andrea>
 <20190513122043.GJ3923@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190513122043.GJ3923@linux.ibm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, May 13, 2019 at 05:20:43AM -0700, Paul E. McKenney wrote:
> On Sun, May 12, 2019 at 03:05:39AM +0200, Andrea Parri wrote:
> > > > > The fix is straightforward.  I just added "rcutorture.shuffle_interval=0"
> > > > > to the TRIVIAL.boot file, which stops rcutorture from shuffling its
> > > > > kthreads around.
> > > > 
> > > > I added the option to the file and I didn't reproduce the issue.
> > > 
> > > Thank you!  May I add your Tested-by?
> > 
> > Please feel free to do so.  But it may be worth to squash "the commits"
> > (and adjust the changelogs accordingly).  And you might want to remove
> > some of those debug checks/prints?
> 
> Revert/remove a number of the commits, but yes.  ;-)
> 
> And remove the extra loop, but leave the single WARN_ON() complaining
> about being on the wrong CPU.

The other "toy" implementation I noticed is based on reader/writer locking.

Would you see value in having that as an additional rcu torture type?

thanks,

 - Joel