From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932960AbcKWG7J (ORCPT ); Wed, 23 Nov 2016 01:59:09 -0500 Received: from out0-135.mail.aliyun.com ([140.205.0.135]:51286 "EHLO out0-135.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932600AbcKWG64 (ORCPT ); Wed, 23 Nov 2016 01:58:56 -0500 X-Greylist: delayed 315 seconds by postgrey-1.27 at vger.kernel.org; Wed, 23 Nov 2016 01:58:54 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R701e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03306;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7CwQ3qN_1479883992; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , "'Linus Torvalds'" Cc: "'Vlastimil Babka'" , "'Marc MERLIN'" , "'linux-mm'" , "'LKML'" , "'Joonsoo Kim'" , "'Tejun Heo'" , "'Greg Kroah-Hartman'" References: <20161121154336.GD19750@merlins.org> <0d4939f3-869d-6fb8-0914-5f74172f8519@suse.cz> <20161121215639.GF13371@merlins.org> <20161122160629.uzt2u6m75ash4ved@merlins.org> <48061a22-0203-de54-5a44-89773bff1e63@suse.cz> <20161123063410.GB2864@dhcp22.suse.cz> In-Reply-To: <20161123063410.GB2864@dhcp22.suse.cz> Subject: Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free Date: Wed, 23 Nov 2016 14:53:12 +0800 Message-ID: <01a101d24556$4262a230$c727e690$@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: AQHgO4m94Y9go+SX0noixQoZYX8mEwKqnmkpAMsvB6wCuQUsNALEIjFdAZ2U7SkB5qdnZqBmef2Q Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, November 23, 2016 2:34 PM Michal Hocko wrote: > @@ -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) No need to check order once more. Plus can we retry without CONFIG_COMPACTION enabled? > + return true; > +#endif > + > /* > * There are setups with compaction disabled which would prefer to loop > * inside the allocator rather than hit the oom killer prematurely. > -- > Michal Hocko > SUSE Labs > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id B8F3E6B0261 for ; Wed, 23 Nov 2016 01:53:27 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id 3so10288784pgd.3 for ; Tue, 22 Nov 2016 22:53:27 -0800 (PST) Received: from out4439.biz.mail.alibaba.com (out4439.biz.mail.alibaba.com. [47.88.44.39]) by mx.google.com with ESMTP id h91si3819611pld.258.2016.11.22.22.53.25 for ; Tue, 22 Nov 2016 22:53:26 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161121154336.GD19750@merlins.org> <0d4939f3-869d-6fb8-0914-5f74172f8519@suse.cz> <20161121215639.GF13371@merlins.org> <20161122160629.uzt2u6m75ash4ved@merlins.org> <48061a22-0203-de54-5a44-89773bff1e63@suse.cz> <20161123063410.GB2864@dhcp22.suse.cz> In-Reply-To: <20161123063410.GB2864@dhcp22.suse.cz> Subject: Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free Date: Wed, 23 Nov 2016 14:53:12 +0800 Message-ID: <01a101d24556$4262a230$c727e690$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , 'Linus Torvalds' Cc: 'Vlastimil Babka' , 'Marc MERLIN' , 'linux-mm' , 'LKML' , 'Joonsoo Kim' , 'Tejun Heo' , 'Greg Kroah-Hartman' On Wednesday, November 23, 2016 2:34 PM Michal Hocko wrote: > @@ -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) No need to check order once more. Plus can we retry without CONFIG_COMPACTION enabled? > + return true; > +#endif > + > /* > * There are setups with compaction disabled which would prefer to loop > * inside the allocator rather than hit the oom killer prematurely. > -- > Michal Hocko > SUSE Labs > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org