From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752175AbcEMELj (ORCPT ); Fri, 13 May 2016 00:11:39 -0400 Received: from out4133-34.mail.aliyun.com ([42.120.133.34]:38912 "EHLO out4133-34.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbcEMELi (ORCPT ); Fri, 13 May 2016 00:11:38 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03302;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_----4oR.nF9_1463112349; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , "'Andrew Morton'" Cc: "'Linus Torvalds'" , "'Johannes Weiner'" , "'Mel Gorman'" , "'David Rientjes'" , "'Tetsuo Handa'" , "'Joonsoo Kim'" , "'Vlastimil Babka'" , , "'LKML'" , "'Michal Hocko'" References: <1463051677-29418-1-git-send-email-mhocko@kernel.org> <1463051677-29418-3-git-send-email-mhocko@kernel.org> In-Reply-To: <1463051677-29418-3-git-send-email-mhocko@kernel.org> Subject: Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION Date: Fri, 13 May 2016 12:05:49 +0800 Message-ID: <02ee01d1accc$bc7e6180$357b2480$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWvLFVEjN1B0l39CtMPfVHi7VoCAG++ePRoJ4mqxA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: Michal Hocko > > Joonsoo has reported that he is able to trigger OOM for !costly high > order requests (heavy fork() workload close the OOM) with the new > oom detection rework. This is because we rely only on should_reclaim_retry > when the compaction is disabled and it only checks watermarks for the > requested order and so we might trigger OOM when there is a lot of free > memory. > > It is not very clear what are the usual workloads when the compaction > is disabled. Relying on high order allocations heavily without any > mechanism to create those orders except for unbound amount of reclaim is > certainly not a good idea. > > To prevent from potential regressions let's help this configuration > some. We have to sacrifice the determinsm though because there simply is > none here possible. should_compact_retry implementation for > !CONFIG_COMPACTION, which was empty so far, will do watermark check > for order-0 on all eligible zones. This will cause retrying until either > the reclaim cannot make any further progress or all the zones are > depleted even for order-0 pages. This means that the number of retries > is basically unbounded for !costly orders but that was the case before > the rework as well so this shouldn't regress. > > Reported-by: Joonsoo Kim > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton > mm/page_alloc.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 620ec002aea2..7e2defbfe55b 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3310,6 +3310,24 @@ should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_fla > enum migrate_mode *migrate_mode, > int compaction_retries) > { > + struct zone *zone; > + struct zoneref *z; > + > + if (!order || order > PAGE_ALLOC_COSTLY_ORDER) > + return false; > + > + /* > + * There are setups with compaction disabled which would prefer to loop > + * inside the allocator rather than hit the oom killer prematurely. Let's > + * give them a good hope and keep retrying while the order-0 watermarks > + * are OK. > + */ > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, > + ac->nodemask) { > + if(zone_watermark_ok(zone, 0, min_wmark_pages(zone), s/if(zone_/if (zone_/ > + ac_classzone_idx(ac), alloc_flags)) > + return true; > + } > return false; > } > #endif /* CONFIG_COMPACTION */ > -- > 2.8.1