On Fri, Jun 28, 2019 at 09:37:12AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 25, 2019 at 09:52:38AM -0700, Paul E. McKenney wrote:
> > Very well, the commit is as shown below. This is on current -rcu,
> > but feel free to take it if you would like, Peter. Just let me know
> > and I will mark it
On Tue, Jun 25, 2019 at 09:52:38AM -0700, Paul E. McKenney wrote:
> Very well, the commit is as shown below. This is on current -rcu,
> but feel free to take it if you would like, Peter. Just let me know
> and I will mark it so that I don't push it myself. (I need to keep
> it in -rcu until I
On Tue, Jun 25, 2019 at 06:20:59PM +0200, Frederic Weisbecker wrote:
> On Tue, Jun 25, 2019 at 07:16:24AM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 25, 2019 at 04:05:38PM +0200, Peter Zijlstra wrote:
> > > On Tue, Jun 25, 2019 at 06:54:30AM -0700, Paul E. McKenney wrote:
> > > > And it allows
On Tue, Jun 25, 2019 at 07:16:24AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 25, 2019 at 04:05:38PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 25, 2019 at 06:54:30AM -0700, Paul E. McKenney wrote:
> > > And it allows dispensing with the initialization. How about like
> > > the following?
> >
On Tue, Jun 25, 2019 at 04:05:38PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 25, 2019 at 06:54:30AM -0700, Paul E. McKenney wrote:
> > And it allows dispensing with the initialization. How about like
> > the following?
>
> Looks good to me!
Limited rcutorture testing looking good thus far.
On Tue, Jun 25, 2019 at 06:54:30AM -0700, Paul E. McKenney wrote:
> And it allows dispensing with the initialization. How about like
> the following?
Looks good to me!
On Tue, Jun 25, 2019 at 02:25:16PM +0200, Frederic Weisbecker wrote:
> On Tue, Jun 25, 2019 at 09:51:39AM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 25, 2019 at 02:43:00AM +0200, Frederic Weisbecker wrote:
> > > Yeah, unfortunately there is no atomic_add_not_zero_return().
> >
> > There is
On Tue, Jun 25, 2019 at 09:51:39AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 25, 2019 at 02:43:00AM +0200, Frederic Weisbecker wrote:
> > Yeah, unfortunately there is no atomic_add_not_zero_return().
>
> There is atomic_fetch_add_unless().
Ah, that could work!
On Tue, Jun 25, 2019 at 02:43:00AM +0200, Frederic Weisbecker wrote:
> Yeah, unfortunately there is no atomic_add_not_zero_return().
There is atomic_fetch_add_unless().
On Tue, Jun 25, 2019 at 02:43:00AM +0200, Frederic Weisbecker wrote:
> On Mon, Jun 24, 2019 at 04:44:22PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 25, 2019 at 01:12:23AM +0200, Frederic Weisbecker wrote:
> > > On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> > > > @@
On Mon, Jun 24, 2019 at 04:44:22PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 25, 2019 at 01:12:23AM +0200, Frederic Weisbecker wrote:
> > On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> > > @@ -3097,13 +3126,21 @@ static void sched_tick_remote(struct work_struct
> > >
On Tue, Jun 25, 2019 at 01:12:23AM +0200, Frederic Weisbecker wrote:
> On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> > @@ -3097,13 +3126,21 @@ static void sched_tick_remote(struct work_struct
> > *work)
> > /*
> > * Run the remote tick once per second (1Hz). This
On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> @@ -3097,13 +3126,21 @@ static void sched_tick_remote(struct work_struct
> *work)
> /*
>* Run the remote tick once per second (1Hz). This arbitrary
>* frequency is large enough to avoid overload but short
On Fri, Jun 21, 2019 at 10:50:27AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 21, 2019 at 10:41:04AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 21, 2019 at 06:34:14AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 21, 2019 at 02:29:27PM +0200, Peter Zijlstra wrote:
> > > > On Fri, Jun 21,
On Fri, Jun 21, 2019 at 10:41:04AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 21, 2019 at 06:34:14AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 21, 2019 at 02:29:27PM +0200, Peter Zijlstra wrote:
> > > On Fri, Jun 21, 2019 at 05:16:30AM -0700, Paul E. McKenney wrote:
> > > > A pair of full
On Fri, Jun 21, 2019 at 06:34:14AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 21, 2019 at 02:29:27PM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 21, 2019 at 05:16:30AM -0700, Paul E. McKenney wrote:
> > > A pair of full hangs at boot (TASKS03 and TREE04), no console output
> > > whatsoever.
On Fri, Jun 21, 2019 at 02:29:27PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 21, 2019 at 05:16:30AM -0700, Paul E. McKenney wrote:
> > A pair of full hangs at boot (TASKS03 and TREE04), no console output
> > whatsoever. Not sure how these changes could cause that, but suspicion
> > falls on
On Fri, Jun 21, 2019 at 05:16:30AM -0700, Paul E. McKenney wrote:
> A pair of full hangs at boot (TASKS03 and TREE04), no console output
> whatsoever. Not sure how these changes could cause that, but suspicion
> falls on sched_tick_offload_init(). Though even that is a bit strange
> because if
On Fri, Jun 21, 2019 at 12:55:03PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 20, 2019 at 03:13:36PM -0700, Paul E. McKenney wrote:
> > So how about the following patch, which passes very light rcutorture
> > testing but should otherwise be regarded as being under suspicion?
>
> Looks good to me,
On Thu, Jun 20, 2019 at 03:13:36PM -0700, Paul E. McKenney wrote:
> So how about the following patch, which passes very light rcutorture
> testing but should otherwise be regarded as being under suspicion?
Looks good to me,
Acked-by: Peter Zijlstra (Intel)
Or, if you want me to apply it, I can
On Thu, Jun 20, 2019 at 11:10:19PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 20, 2019 at 09:01:18AM -0700, Paul E. McKenney wrote:
>
> > > > +#define TICK_SCHED_REMOTE_OFFLINE 0
> > > > +#define TICK_SCHED_REMOTE_RUNNING 1
> > > > +#define TICK_SCHED_REMOTE_OFFLINING2
> > >
> > >
On Thu, Jun 20, 2019 at 09:01:18AM -0700, Paul E. McKenney wrote:
> > > +#define TICK_SCHED_REMOTE_OFFLINE0
> > > +#define TICK_SCHED_REMOTE_RUNNING1
> > > +#define TICK_SCHED_REMOTE_OFFLINING 2
> >
> > That seems a daft set of values; consider { RUNNING, OFFLINING, OFFLINE
On Thu, Jun 20, 2019 at 02:10:32PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 19, 2019 at 11:19:03AM -0700, Paul E. McKenney wrote:
> > [ Hearing no objections and given no test failures in multiple weeks of
> > rcutorture testing, I intend to submit this to the upcoming merge
> > window.
On Wed, Jun 19, 2019 at 11:19:03AM -0700, Paul E. McKenney wrote:
> [ Hearing no objections and given no test failures in multiple weeks of
> rcutorture testing, I intend to submit this to the upcoming merge
> window. Thoughts? ]
I can't remember seeing this before; but then, there's a ton
[ Hearing no objections and given no test failures in multiple weeks of
rcutorture testing, I intend to submit this to the upcoming merge
window. Thoughts? ]
The TASKS03 and TREE04 rcutorture scenarios produce the following
lockdep complaint:
On Fri, May 31, 2019 at 03:36:40AM +0200, Frederic Weisbecker wrote:
> On Thu, May 30, 2019 at 05:58:09AM -0700, Paul E. McKenney wrote:
> > It turns out that tick_broadcast_offline() was an innocent bystander.
> > After all, interrupts are supposed to be disabled throughout
> >
On Thu, May 30, 2019 at 05:58:09AM -0700, Paul E. McKenney wrote:
> It turns out that tick_broadcast_offline() was an innocent bystander.
> After all, interrupts are supposed to be disabled throughout
> take_cpu_down(), and therefore should have been disabled upon entry to
>
On Wed, May 29, 2019 at 11:19:41AM -0700, Paul E. McKenney wrote:
> On Tue, May 28, 2019 at 01:07:29PM -0700, Thomas Gleixner wrote:
[ . . . ]
> > What?
> >
> > take_cpu_down() is called from multi_cpu_stop() with interrupts disabled.
> >
> > So this is just papering over the fact that
On Tue, May 28, 2019 at 01:07:29PM -0700, Thomas Gleixner wrote:
> On Mon, 27 May 2019, Paul E. McKenney wrote:
>
> > The TASKS03 and TREE04 rcutorture scenarios produce the following
> > lockdep complaint:
> >
> >
> > WARNING: inconsistent lock state
> >
On Mon, 27 May 2019, Paul E. McKenney wrote:
> The TASKS03 and TREE04 rcutorture scenarios produce the following
> lockdep complaint:
>
>
> WARNING: inconsistent lock state
> 5.2.0-rc1+ #513 Not tainted
>
> inconsistent
The TASKS03 and TREE04 rcutorture scenarios produce the following
lockdep complaint:
WARNING: inconsistent lock state
5.2.0-rc1+ #513 Not tainted
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
migration/1/14
31 matches
Mail list logo
