[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170118005242.23379a74@pog.tecnopolis.ca>
Date: Wed, 18 Jan 2017 00:52:42 -0600
From: Trevor Cordes <trevor@...nopolis.ca>
To: Mel Gorman <mgorman@...hsingularity.net>
Cc: Michal Hocko <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Minchan Kim <minchan@...nel.org>,
Rik van Riel <riel@...riel.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Subject: Re: 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!
Powered by blists - more mailing lists