Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1438013 > unrolled thread

Re: divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault vanilla 4.4.6

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: divide error: 0000 [#1] SMP in task_numa_migrate -  handle_mm_fault vanilla 4.4.6 Campbell Steven <casteven@gmail.com> - 2016-07-07 01:30 +0200
    Re: divide error: 0000 [#1] SMP in task_numa_migrate -  handle_mm_fault vanilla 4.4.6 Peter Zijlstra <peterz@infradead.org> - 2016-07-07 09:50 +0200
      Re: divide error: 0000 [#1] SMP in task_numa_migrate -  handle_mm_fault vanilla 4.4.6 Greg KH <greg@kroah.com> - 2016-07-09 07:30 +0200
      Re: divide error: 0000 [#1] SMP in task_numa_migrate -  handle_mm_fault vanilla 4.4.6 Greg KH <greg@kroah.com> - 2016-07-12 01:10 +0200
        Re: divide error: 0000 [#1] SMP in task_numa_migrate -  handle_mm_fault vanilla 4.4.6 Peter Zijlstra <peterz@infradead.org> - 2016-07-12 15:20 +0200
          Re: divide error: 0000 [#1] SMP in task_numa_migrate -  handle_mm_fault vanilla 4.4.6 Greg KH <greg@kroah.com> - 2016-07-13 02:30 +0200

#1438013 — Re: divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault vanilla 4.4.6

On 22 June 2016 at 18:13, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Jun 22, 2016 at 01:19:54PM +1200, Campbell Steven wrote:
>> >>>>>>> This suggests the CONFIG_FAIR_GROUP_SCHED version of task_h_load:
>> >>>>>>>
>> >>>>>>>         update_cfs_rq_h_load(cfs_rq);
>> >>>>>>>         return div64_ul(p->se.avg.load_avg * cfs_rq->h_load,
>> >>>>>>>                         cfs_rq_load_avg(cfs_rq) + 1);
>> >>>>>>>
>
>
> ---
> commit 8974189222159154c55f24ddad33e3613960521a
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Thu Jun 16 10:50:40 2016 +0200
>
>     sched/fair: Fix cfs_rq avg tracking underflow
>
>     As per commit:
>
>       b7fa30c9cc48 ("sched/fair: Fix post_init_entity_util_avg() serialization")
>
>     > the code generated from update_cfs_rq_load_avg():
>     >
>     >   if (atomic_long_read(&cfs_rq->removed_load_avg)) {
>     >           s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
>     >           sa->load_avg = max_t(long, sa->load_avg - r, 0);
>     >           sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
>     >           removed_load = 1;
>     >   }


Hi Peter,

I just wanted to report back to say thanks for this, and we have (and
others) have tested this out in 4.7 rc6 and have not been able to
repeat the issue. It seems that anyone running busy ceph osd's or high
load KVM instances is able to trigger this on a dual socket box pretty
easily.

Since these early reports from Stefan and I it looks like it's been
hit but alot more folks now so I'd like to ask what the process is for
getting this backported into 4.6, 4.5 and 4.4 as in our testing all
those versions for their latest point release seem to have the same
problem.

Thanks

Campbell

[toc] | [next] | [standalone]

#1438251

On Thu, Jul 07, 2016 at 11:20:36AM +1200, Campbell Steven wrote:

> > commit 8974189222159154c55f24ddad33e3613960521a
> > Author: Peter Zijlstra <peterz@infradead.org>
> > Date:   Thu Jun 16 10:50:40 2016 +0200

> Since these early reports from Stefan and I it looks like it's been
> hit but alot more folks now so I'd like to ask what the process is for
> getting this backported into 4.6, 4.5 and 4.4 as in our testing all
> those versions for their latest point release seem to have the same
> problem.

I think this should do; Greg is on Cc and will mark the commit
somewhere. It is already in Linus' tree and should indeed be sufficient.

It has a Fixes tag referring the commit that introduced it, which IIRC
is somewhere around v4.2.

Greg, anything else required?

[toc] | [prev] | [next] | [standalone]

#1439898

On Thu, Jul 07, 2016 at 09:42:32AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 07, 2016 at 11:20:36AM +1200, Campbell Steven wrote:
> 
> > > commit 8974189222159154c55f24ddad33e3613960521a
> > > Author: Peter Zijlstra <peterz@infradead.org>
> > > Date:   Thu Jun 16 10:50:40 2016 +0200
> 
> > Since these early reports from Stefan and I it looks like it's been
> > hit but alot more folks now so I'd like to ask what the process is for
> > getting this backported into 4.6, 4.5 and 4.4 as in our testing all
> > those versions for their latest point release seem to have the same
> > problem.
> 
> I think this should do; Greg is on Cc and will mark the commit
> somewhere. It is already in Linus' tree and should indeed be sufficient.
> 
> It has a Fixes tag referring the commit that introduced it, which IIRC
> is somewhere around v4.2.
> 
> Greg, anything else required?

Nope, that should be fine.

greg k-h

[toc] | [prev] | [next] | [standalone]

#1440963

On Thu, Jul 07, 2016 at 09:42:32AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 07, 2016 at 11:20:36AM +1200, Campbell Steven wrote:
> 
> > > commit 8974189222159154c55f24ddad33e3613960521a
> > > Author: Peter Zijlstra <peterz@infradead.org>
> > > Date:   Thu Jun 16 10:50:40 2016 +0200
> 
> > Since these early reports from Stefan and I it looks like it's been
> > hit but alot more folks now so I'd like to ask what the process is for
> > getting this backported into 4.6, 4.5 and 4.4 as in our testing all
> > those versions for their latest point release seem to have the same
> > problem.
> 
> I think this should do; Greg is on Cc and will mark the commit
> somewhere. It is already in Linus' tree and should indeed be sufficient.
> 
> It has a Fixes tag referring the commit that introduced it, which IIRC
> is somewhere around v4.2.
> 
> Greg, anything else required?

Oops, this commit does not apply cleanly to 4.6 or 4.4-stable trees.
Can someone send me the backported verision that they have tested to
work properly so I can queue it up?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1441344

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 11, 2016 at 03:33:53PM -0700, Greg KH wrote:

> Oops, this commit does not apply cleanly to 4.6 or 4.4-stable trees.
> Can someone send me the backported verision that they have tested to
> work properly so I can queue it up?

I've never actually been able to reproduce, but the attached patches
apply, the reject was trivial.

They seem to compile and boot on my main test rig, but nothing else was
done but build the next kernel with it.

[toc] | [prev] | [next] | [standalone]

#1441931

On Tue, Jul 12, 2016 at 03:12:35PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 11, 2016 at 03:33:53PM -0700, Greg KH wrote:
> 
> > Oops, this commit does not apply cleanly to 4.6 or 4.4-stable trees.
> > Can someone send me the backported verision that they have tested to
> > work properly so I can queue it up?
> 
> I've never actually been able to reproduce, but the attached patches
> apply, the reject was trivial.
> 
> They seem to compile and boot on my main test rig, but nothing else was
> done but build the next kernel with it.

Thanks for these, now applied.

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web