lkml.org 
[lkml]   [2017]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mm, vmscan: commit makes PAE kernel crash nightly (bisected)
On 2017-01-16 Mel Gorman wrote:
> > > You can easily check whether this is memcg related by trying to
> > > run the same workload with cgroup_disable=memory kernel command
> > > line parameter. This will put all the memcg specifics out of the
> > > way.
> >
> > I will try booting now into cgroup_disable=memory to see if that
> > helps at all. I'll reply back in 48 hours, or when it oom's,
> > whichever comes first.
> >
>
> Thanks.

It has successfully survived 70 hours and 2 3am cycles (when it
normally oom's) with your first patch *and* cgroup_disable=memory
grafted on Fedora's 4.8.13. Since it has never survived 2 3am cycles,
I strongly suspect the cgroup_disable=memory mitigates my bug.

> > Also, should I bother trying the latest git HEAD to see if that
> > solves anything? Thanks!
>
> That's worth trying. If that also fails then could you try the
> following hack to encourage direct reclaim to reclaim slab when
> buffers are over the limit please?
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 532a2a750952..46aac487b89a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> *zonelist, struct scan_control *sc) continue;
>
> if (sc->priority != DEF_PRIORITY &&
> + !buffer_heads_over_limit &&
> !pgdat_reclaimable(zone->zone_pgdat))
> continue; /* Let kswapd poll
> it */

What's the next best step? HEAD? HEAD + the above patch? A new
patch? I'll start a HEAD compile until I hear more. I assume I should
test without cgroup_disable=memory as that's just a kludge/workaround,
right?

Also, is there a way to spot the slab pressure you are talking about
before oom's occur? slabinfo? I suppose I'd be able to see some
counter slowly getting too high or low? Thanks!

\
 
 \ /
  Last update: 2017-01-18 07:59    [W:1.022 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site