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

Groups > linux.kernel > #1467547

Re: OOM detection regressions since 4.7

Show all headers | View raw

On Mon 22-08-16 06:05:28, Greg KH wrote:
> On Mon, Aug 22, 2016 at 11:37:07AM +0200, Michal Hocko wrote:
[...]
> > > From 899b738538de41295839dca2090a774bdd17acd2 Mon Sep 17 00:00:00 2001
> > > From: Michal Hocko <mhocko@suse.com>
> > > Date: Mon, 22 Aug 2016 10:52:06 +0200
> > > Subject: [PATCH] mm, oom: prevent pre-mature OOM killer invocation for high
> > >  order request
> > > 
> > > There have been several reports about pre-mature OOM killer invocation
> > > in 4.7 kernel when order-2 allocation request (for the kernel stack)
> > > invoked OOM killer even during basic workloads (light IO or even kernel
> > > compile on some filesystems). In all reported cases the memory is
> > > fragmented and there are no order-2+ pages available. There is usually
> > > a large amount of slab memory (usually dentries/inodes) and further
> > > debugging has shown that there are way too many unmovable blocks which
> > > are skipped during the compaction. Multiple reporters have confirmed that
> > > the current linux-next which includes [1] and [2] helped and OOMs are
> > > not reproducible anymore. A simpler fix for the stable is to simply
> > > ignore the compaction feedback and retry as long as there is a reclaim
> > > progress for high order requests which we used to do before. We already
> > > do that for CONFING_COMPACTION=n so let's reuse the same code when
> > > compaction is enabled as well.
> > > 
> > > [1] http://lkml.kernel.org/r/20160810091226.6709-1-vbabka@suse.cz
> > > [2] http://lkml.kernel.org/r/f7a9ea9d-bb88-bfd6-e340-3a933559305a@suse.cz
> > > 
> > > Fixes: 0a0337e0d1d1 ("mm, oom: rework oom detection")
> > > Signed-off-by: Michal Hocko <mhocko@suse.com>
> > > ---
> > >  mm/page_alloc.c | 50 ++------------------------------------------------
> > >  1 file changed, 2 insertions(+), 48 deletions(-)
> 
> So, if this goes into Linus's tree, can you let stable@vger.kernel.org
> know about it so we can add it to the 4.7-stable tree?  Otherwise
> there's not much I can do here now, right?

My plan would be actually to not push this to Linus because we have a
proper fix for Linus tree. It is just that the fix is quite large and I
felt like the stable should get the most simple fix possible, which is
this partial revert. So, what I am trying to tell is to push a non-linus
patch to stable as it is simpler.
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: OOM detection regressions since 4.7 Michal Hocko <mhocko@kernel.org> - 2016-08-22 11:40 +0200
  Re: OOM detection regressions since 4.7 Greg KH <gregkh@linuxfoundation.org> - 2016-08-22 12:20 +0200
    Re: OOM detection regressions since 4.7 Michal Hocko <mhocko@kernel.org> - 2016-08-22 13:00 +0200
      Re: OOM detection regressions since 4.7 Greg KH <gregkh@linuxfoundation.org> - 2016-08-22 15:40 +0200
        Re: OOM detection regressions since 4.7 Michal Hocko <mhocko@kernel.org> - 2016-08-22 15:50 +0200
          Re: OOM detection regressions since 4.7 Greg KH <gregkh@linuxfoundation.org> - 2016-08-22 16:10 +0200
          Re: OOM detection regressions since 4.7 Andrew Morton <akpm@linux-foundation.org> - 2016-08-23 00:10 +0200
            Re: OOM detection regressions since 4.7 Michal Hocko <mhocko@kernel.org> - 2016-08-23 11:00 +0200
              Re: OOM detection regressions since 4.7 Olaf Hering <olaf@aepfle.de> - 2016-08-25 09:30 +0200
              Re: OOM detection regressions since 4.7 Michal Hocko <mhocko@kernel.org> - 2016-08-25 09:40 +0200

csiph-web