On Mon, May 13, 2019 at 11:37:14AM -0400, Joel Fernandes wrote:
> 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"
>
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
On Mon, May 13, 2019 at 10:10:52AM +0200, Peter Zijlstra wrote:
> On Fri, May 10, 2019 at 04:07:42PM -0700, Paul E. McKenney wrote:
> > > The below trace explain the issue. Some Paul person did it, see below.
> > > It's broken per construction :-)
> >
> > *facepalm* Hence the very strange ->cpus_
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 a
On Fri, May 10, 2019 at 04:07:42PM -0700, Paul E. McKenney wrote:
> > The below trace explain the issue. Some Paul person did it, see below.
> > It's broken per construction :-)
>
> *facepalm* Hence the very strange ->cpus_allowed mask. I really
> should have figured that one out.
I guess it's
> > > 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?
Plea
On Sat, May 11, 2019 at 11:45:20PM +0200, Andrea Parri wrote:
> > > The below trace explain the issue. Some Paul person did it, see below.
> > > It's broken per construction :-)
> >
> > *facepalm* Hence the very strange ->cpus_allowed mask. I really
> > should have figured that one out.
> >
> >
> > The below trace explain the issue. Some Paul person did it, see below.
> > It's broken per construction :-)
>
> *facepalm* Hence the very strange ->cpus_allowed mask. I really
> should have figured that one out.
>
> The fix is straightforward. I just added "rcutorture.shuffle_interval=0"
>
On Fri, May 10, 2019 at 02:08:19PM +0200, Peter Zijlstra wrote:
> On Thu, May 09, 2019 at 12:36:25PM -0700, Paul E. McKenney wrote:
> > I forward-ported the relevant patches from -rcu and placed them on -rcu
> > branch peterz.2019.05.09a, and this is what produced the output above.
> >
> > Any oth
On Thu, May 09, 2019 at 12:36:25PM -0700, Paul E. McKenney wrote:
> I forward-ported the relevant patches from -rcu and placed them on -rcu
> branch peterz.2019.05.09a, and this is what produced the output above.
>
> Any other debugging thoughts?
>
> Or, if you wish, you can reproduce by running
> > > Adding some "sched" folks in Cc: hopefully, they can shed some light
> > > about this.
> >
> > +Thomas, +Sebastian
> >
> > Thread starts here:
> >
> > http://lkml.kernel.org/r/20190427180246.ga15...@linux.ibm.com
>
> Peter Zijlstra kindly volunteered over IRC to look at this more closely
On Thu, May 09, 2019 at 11:56:35PM +0200, Andrea Parri wrote:
> On Thu, May 09, 2019 at 11:40:25PM +0200, Andrea Parri wrote:
> > On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote:
> > > > On Wed, May 01, 2019 at
On Thu, May 09, 2019 at 11:40:25PM +0200, Andrea Parri wrote:
> On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote:
> > On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote:
> > > On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote:
> > > > On Wed, May 01, 201
On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote:
> On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote:
> > On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote:
> > > On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote:
> > > > On Wed, 1 May 201
On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote:
> On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote:
> > On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote:
> > > On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote:
> > > > On Wed, 1 May 201
On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote:
> On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote:
> > On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote:
> > > On Wed, 1 May 2019 12:12:13 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > >
> > > > OK
On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote:
> On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote:
> > On Wed, 1 May 2019 12:12:13 -0700
> > "Paul E. McKenney" wrote:
> >
> >
> > > OK, what I did was to apply the patch at the end of this email to -rcu
> > > branc
On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote:
> On Wed, 1 May 2019 12:12:13 -0700
> "Paul E. McKenney" wrote:
>
>
> > OK, what I did was to apply the patch at the end of this email to -rcu
> > branch dev, then run rcutorture as follows:
> >
> > nohup tools/testing/selftests/rc
On Wed, 1 May 2019 12:12:13 -0700
"Paul E. McKenney" wrote:
> OK, what I did was to apply the patch at the end of this email to -rcu
> branch dev, then run rcutorture as follows:
>
> nohup tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 8 --duration 2
> --configs "TRIVIAL" --bootargs
> "
On Tue, Apr 30, 2019 at 01:55:51PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 30, 2019 at 03:51:30AM -0700, Paul E. McKenney wrote:
> > > Then I'm not entirely sure how we can return 0 and not run on the
> > > expected CPU. If we look at __set_cpus_allowed_ptr(), the only paths out
> > > to 0 are:
On Tue, Apr 30, 2019 at 03:51:30AM -0700, Paul E. McKenney wrote:
> > Then I'm not entirely sure how we can return 0 and not run on the
> > expected CPU. If we look at __set_cpus_allowed_ptr(), the only paths out
> > to 0 are:
> >
> > - if the mask didn't change
> > - if we already run inside th
On Tue, Apr 30, 2019 at 12:03:18PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 27, 2019 at 11:02:46AM -0700, Paul E. McKenney wrote:
>
> > This actually passes rcutorture. But, as Andrea noted, not klitmus.
> > After some investigation, it turned out that klitmus was creating kthreads
> > with PF_
On Sat, Apr 27, 2019 at 11:02:46AM -0700, Paul E. McKenney wrote:
> This actually passes rcutorture. But, as Andrea noted, not klitmus.
> After some investigation, it turned out that klitmus was creating kthreads
> with PF_NO_SETAFFINITY, hence the failures. But that prompted me to
> put checks
Hello, Peter!
TL;DR: If a normal !PF_NO_SETAFFINITY kthread invokes sched_setaffinity(),
and sched_setaffinity() returns 0, is it expected behavior for that
kthread to be running on some CPU other than one of the ones specified by
the in_mask argument? All CPUs are online, and there is no CPU-hot
24 matches
Mail list logo
