From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f71.google.com (mail-pa0-f71.google.com [209.85.220.71]) by kanga.kvack.org (Postfix) with ESMTP id C51D06B0038 for ; Tue, 20 Sep 2016 16:34:38 -0400 (EDT) Received: by mail-pa0-f71.google.com with SMTP id fu14so53026809pad.0 for ; Tue, 20 Sep 2016 13:34:38 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com. [2607:f8b0:400e:c00::22c]) by mx.google.com with ESMTPS id a5si36628243pac.173.2016.09.20.13.34.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Sep 2016 13:34:37 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id p64so10883749pfb.1 for ; Tue, 20 Sep 2016 13:34:37 -0700 (PDT) Date: Tue, 20 Sep 2016 13:34:29 -0700 (PDT) From: Hugh Dickins Subject: Re: [PATCH v3] mm,ksm: fix endless looping in allocating memory when ksm enable In-Reply-To: <1474358125-29716-1-git-send-email-zhongjiang@huawei.com> Message-ID: References: <1474358125-29716-1-git-send-email-zhongjiang@huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: zhongjiang Cc: hughd@google.com, mhocko@suse.cz, penguin-kernel@i-love.sakura.ne.jp, rientjes@google.com, vbabka@suse.cz, akpm@linux-foundation.org, linux-mm@kvack.org On Tue, 20 Sep 2016, zhongjiang wrote: > From: zhong jiang > > I hit the following hung task when runing a OOM LTP test case with > 4.1 kernel. > > Call trace: > [] __switch_to+0x74/0x8c > [] __schedule+0x23c/0x7bc > [] schedule+0x3c/0x94 > [] rwsem_down_write_failed+0x214/0x350 > [] down_write+0x64/0x80 > [] __ksm_exit+0x90/0x19c > [] mmput+0x118/0x11c > [] do_exit+0x2dc/0xa74 > [] do_group_exit+0x4c/0xe4 > [] get_signal+0x444/0x5e0 > [] do_signal+0x1d8/0x450 > [] do_notify_resume+0x70/0x78 > > The oom victim cannot terminate because it needs to take mmap_sem for > write while the lock is held by ksmd for read which loops in the page > allocator > > ksm_do_scan > scan_get_next_rmap_item > down_read > get_next_rmap_item > alloc_rmap_item #ksmd will loop permanently. > > There is not way forward because the oom victim cannot release any > memory in 4.1 based kernel. Since 4.6 we have the oom reaper which would > solve this problem because it would release the memory asynchronously. > Nevertheless we can relax alloc_rmap_item requirements and use > __GFP_NORETRY because the allocation failure is acceptable as > ksm_do_scan would just retry later after the lock got dropped. > > Such a patch would be also easy to backport to older stable kernels > which do not have oom_reaper. > > While we are at it add GFP_NOWARN as the admin doesn't have to be > alarmed by the allocation failure. > > CC: > Suggested-by: Hugh Dickins > Suggested-by: Michal Hocko > Signed-off-by: zhong jiang Thanks, Acked-by: Hugh Dickins > --- > mm/ksm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/ksm.c b/mm/ksm.c > index 73d43ba..5048083 100644 > --- a/mm/ksm.c > +++ b/mm/ksm.c > @@ -283,7 +283,8 @@ static inline struct rmap_item *alloc_rmap_item(void) > { > struct rmap_item *rmap_item; > > - rmap_item = kmem_cache_zalloc(rmap_item_cache, GFP_KERNEL); > + rmap_item = kmem_cache_zalloc(rmap_item_cache, GFP_KERNEL | > + __GFP_NORETRY | __GFP_NOWARN); > if (rmap_item) > ksm_rmap_items++; > return rmap_item; > -- > 1.8.3.1 > > -- > 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 > -- 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