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 EF2156B025E for ; Tue, 20 Sep 2016 03:15:23 -0400 (EDT) Received: by mail-pa0-f71.google.com with SMTP id fu14so18119286pad.0 for ; Tue, 20 Sep 2016 00:15:23 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com. [58.251.152.64]) by mx.google.com with ESMTP id z1si31186430pab.287.2016.09.20.00.15.22 for ; Tue, 20 Sep 2016 00:15:23 -0700 (PDT) Message-ID: <57E0E177.6040800@huawei.com> Date: Tue, 20 Sep 2016 15:12:55 +0800 From: zhong jiang MIME-Version: 1.0 Subject: Re: [PATCH v2] mm,ksm: fix endless looping in allocating memory when ksm enable References: <1474350613-25041-1-git-send-email-zhongjiang@huawei.com> <20160920070743.GB5477@dhcp22.suse.cz> In-Reply-To: <20160920070743.GB5477@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: hughd@google.com, akpm@linux-foundation.org, linux-mm@kvack.org On 2016/9/20 15:07, Michal Hocko wrote: > [CCing Tetsuo again - please make sure you CC everybody who did respond > in earlier versions of the patch] > > I am sorry to insist here but this doesn't address the previous review > feedback. Let me try to show you what I would find much better. I do not > insist on this precise wording of course but I do insist on mentioning > the current state and making clear why GFP_NORETRY is really ok. > > On Tue 20-09-16 13:50:13, zhongjiang wrote: >> From: zhong jiang >> >> I hit the following issue when run a OOM case of the LTP and >> ksm enable. > " > I hit the following hung task when running an 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 >> >> it will leads to a hung task because the exiting task cannot get the >> mmap sem for write. but the root cause is that the ksmd holds it for >> read while allocateing memory which just takes ages to complete. >> and ksmd will loop in the following path. > " > 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 >> --- >> 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 Thanks you for advice, I will modify it now . -- 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