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


Groups > linux.kernel > #1528279

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

From Vlastimil Babka <vbabka@suse.cz>
Newsgroups linux.kernel
Subject Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free
Date 2016-11-23 11:20 +0100
Message-ID <sGCOJ-3Ax-1@gated-at.bofh.it> (permalink)
References (2 earlier) <sG56q-77c-7@gated-at.bofh.it> <sGlNT-Wt-1@gated-at.bofh.it> <sGlXA-18B-43@gated-at.bofh.it> <sGp57-32O-11@gated-at.bofh.it> <sGznQ-1kN-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 11/23/2016 07:34 AM, Michal Hocko wrote:
> On Tue 22-11-16 11:38:47, Linus Torvalds wrote:
>> On Tue, Nov 22, 2016 at 8:14 AM, Vlastimil Babka <vbabka@suse.cz> wrote:
>>>
>>> Thanks a lot for the testing. So what do we do now about 4.8? (4.7 is
>>> already EOL AFAICS).
>>>
>>> - send the patch [1] as 4.8-only stable.
>>
>> I think that's the right thing to do. It's pretty small, and the
>> argument that it changes the oom logic too much is pretty bogus, I
>> think. The oom logic in 4.8 is simply broken. Let's get it fixed.
>> Changing it is the point.
>
> The point I've tried to make is that it is not should_reclaim_retry
> which is broken. It's an overly optimistic reliance on the compaction
> to do it's work which led to all those issues. My previous fix
> 31e49bfda184 ("mm, oom: protect !costly allocations some more for
> !CONFIG_COMPACTION") tried to cope with that by checking the order-0
> watermark which has proven to help most users. Now it didn't cover
> everybody obviously. Rather than fiddling with fine tuning of these
> heuristics I think it would be safer to simply admit that high order
> OOM detection doesn't work in 4.8 kernel and so do not declare the OOM
> killer for those requests at all. The risk of such a change is not big
> because there usually are order-0 requests happening all the time so if
> we are really OOM we would trigger the OOM eventually.
>
> So I am proposing this for 4.8 stable tree instead
> ---
> commit b2ccdcb731b666aa28f86483656c39c5e53828c7
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Wed Nov 23 07:26:30 2016 +0100
>
>     mm, oom: stop pre-mature high-order OOM killer invocations
>
>     31e49bfda184 ("mm, oom: protect !costly allocations some more for
>     !CONFIG_COMPACTION") was an attempt to reduce chances of pre-mature OOM
>     killer invocation for high order requests. It seemed to work for most
>     users just fine but it is far from bullet proof and obviously not
>     sufficient for Marc who has reported pre-mature OOM killer invocations
>     with 4.8 based kernels. 4.9 will all the compaction improvements seems
>     to be behaving much better but that would be too intrusive to backport
>     to 4.8 stable kernels. Instead this patch simply never declares OOM for
>     !costly high order requests. We rely on order-0 requests to do that in
>     case we are really out of memory. Order-0 requests are much more common
>     and so a risk of a livelock without any way forward is highly unlikely.
>
>     Reported-by: Marc MERLIN <marc@merlins.org>
>     Signed-off-by: Michal Hocko <mhocko@suse.com>

This should effectively restore the 4.6 logic, so I'm fine with it for 
stable, if it passes testing.

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a2214c64ed3c..7401e996009a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3161,6 +3161,16 @@ should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_fla
>  	if (!order || order > PAGE_ALLOC_COSTLY_ORDER)
>  		return false;
>
> +#ifdef CONFIG_COMPACTION
> +	/*
> +	 * This is a gross workaround to compensate a lack of reliable compaction
> +	 * operation. We cannot simply go OOM with the current state of the compaction
> +	 * code because this can lead to pre mature OOM declaration.
> +	 */
> +	if (order <= PAGE_ALLOC_COSTLY_ORDER)
> +		return true;
> +#endif
> +
>  	/*
>  	 * There are setups with compaction disabled which would prefer to loop
>  	 * inside the allocator rather than hit the oom killer prematurely.
>

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


Thread

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Vlastimil Babka <vbabka@suse.cz> - 2016-11-21 23:00 +0100
  Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free Marc MERLIN <marc@merlins.org> - 2016-11-21 23:20 +0100
    [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in  blkcg Tejun Heo <tj@kernel.org> - 2016-11-22 00:10 +0100
      Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations  in blkcg Vlastimil Babka <vbabka@suse.cz> - 2016-11-22 16:50 +0100
        Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort  allocations in blkcg Tejun Heo <tj@kernel.org> - 2016-11-22 18:10 +0100
          Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations  in blkcg Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-22 23:20 +0100
            Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations  in blkcg Vlastimil Babka <vbabka@suse.cz> - 2016-11-23 10:00 +0100
      Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations  in blkcg Jens Axboe <axboe@kernel.dk> - 2016-11-22 17:10 +0100
    Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Marc MERLIN <marc@merlins.org> - 2016-11-22 17:10 +0100
      Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Vlastimil Babka <vbabka@suse.cz> - 2016-11-22 17:20 +0100
        Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Michal Hocko <mhocko@kernel.org> - 2016-11-22 17:30 +0100
          Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Marc MERLIN <marc@merlins.org> - 2016-11-22 17:50 +0100
        Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-11-22 17:40 +0100
        Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-22 20:40 +0100
          Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Michal Hocko <mhocko@kernel.org> - 2016-11-23 07:40 +0100
            Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-11-23 08:00 +0100
              Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Michal Hocko <mhocko@kernel.org> - 2016-11-23 08:10 +0100
            Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Vlastimil Babka <vbabka@suse.cz> - 2016-11-23 11:20 +0100
        Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of  RAM that should be free Simon Kirby <sim@hostway.ca> - 2016-11-22 23:10 +0100

csiph-web