lkml.org 
[lkml]   [2016]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] OOM detection rework v4
On Thu, 3 Mar 2016, Michal Hocko wrote:
> On Thu 03-03-16 01:54:43, Hugh Dickins wrote:
> > On Tue, 1 Mar 2016, Michal Hocko wrote:
> [...]
> > > So I have tried the following:
> > > diff --git a/mm/compaction.c b/mm/compaction.c
> > > index 4d99e1f5055c..7364e48cf69a 100644
> > > --- a/mm/compaction.c
> > > +++ b/mm/compaction.c
> > > @@ -1276,6 +1276,9 @@ static unsigned long __compaction_suitable(struct zone *zone, int order,
> > > alloc_flags))
> > > return COMPACT_PARTIAL;
> > >
> > > + if (order <= PAGE_ALLOC_COSTLY_ORDER)
> > > + return COMPACT_CONTINUE;
> > > +
> >
> > I gave that a try just now, but it didn't help me: OOMed much sooner,
> > after doing half as much work.

I think I exaggerated: sooner, but not _much_ sooner; and I cannot
see now what I based that estimate of "half as much work" on.

>
> I do not have an explanation why it would cause oom sooner but this
> turned out to be incomplete. There is another wmaark check deeper in the
> compaction path. Could you try the one from
> http://lkml.kernel.org/r/20160302130022.GG26686@dhcp22.suse.cz

I've now added that in: it corrects the "sooner", but does not make
any difference to the fact of OOMing for me.

Hugh

>
> I will try to find a machine with more CPUs and try to reproduce this in
> the mean time.
>
> I will also have a look at the data you have collected.
> --
> Michal Hocko
> SUSE Labs

\
 
 \ /
  Last update: 2016-03-03 22:41    [W:0.385 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site