Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

[Michal Hocko]

On Wed 25-01-17 04:02:46, Trevor Cordes wrote:
> On 2017-01-23 Mel Gorman wrote:
> > On Sun, Jan 22, 2017 at 06:45:59PM -0600, Trevor Cordes wrote:
> > > On 2017-01-20 Mel Gorman wrote:  
> > > > > 
> > > > > Thanks for the OOM report. I was expecting it to be a particular
> > > > > shape and my expectations were not matched so it took time to
> > > > > consider it further. Can you try the cumulative patch below? It
> > > > > combines three patches that
> > > > > 
> > > > > 1. Allow slab shrinking even if the LRU patches are
> > > > > unreclaimable in direct reclaim
> > > > > 2. Shrinks slab based once based on the contents of all memcgs
> > > > > instead of shrinking one at a time
> > > > > 3. Tries to shrink slabs if the lowmem usage is too high
> > > > > 
> > > > > Unfortunately it's only boot tested on x86-64 as I didn't get
> > > > > the chance to setup an i386 test bed.
> > > > >     
> > > > 
> > > > There was one major flaw in that patch. This version fixes it and
> > > > addresses other minor issues. It may still be too agressive
> > > > shrinking slab but worth trying out. Thanks.  
> > > 
> > > I ran with your patch below and it oom'd on the first night.  It was
> > > weird, it didn't hang the system, and my rebooter script started a
> > > reboot but the system never got more than half down before it just
> > > sat there in a weird state where a local console user could still
> > > login but not much was working.  So the patches don't seem to solve
> > > the problem.
> > > 
> > > For the above compile I applied your patches to 4.10.0-rc4+, I hope
> > > that's ok.
> > >   
> > 
> > It would be strongly preferred to run them on top of Michal's other
> > fixes. The main reason it's preferred is because this OOM differs from
> > earlier ones in that it OOM killed from GFP_NOFS|__GFP_NOFAIL context.
> > That meant that the slab shrinking could not happen from direct
> > reclaim so the balancing from my patches would not occur.  As
> > Michal's other patches affect how kswapd behaves, it's important.
> 
> OK, I patched & compiled mhocko's git tree from the other day 4.9.0+.
> (To confirm, weird, but mhocko's git tree I'm using from a couple of
> weeks ago shows the newest commit (git log) is
> 69973b830859bc6529a7a0468ba0d80ee5117826 "Linux 4.9"?  Let me know if
> I'm doing something wrong, see below.)

My fault. I should have noted that you should use since-4.9 branch.
-- 
Michal Hocko
SUSE Labs