From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f200.google.com (mail-wr0-f200.google.com [209.85.128.200]) by kanga.kvack.org (Postfix) with ESMTP id 1FF6F280553 for ; Tue, 9 May 2017 08:41:23 -0400 (EDT) Received: by mail-wr0-f200.google.com with SMTP id q91so19670037wrb.8 for ; Tue, 09 May 2017 05:41:23 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id x66si72372wme.98.2017.05.09.05.41.21 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 09 May 2017 05:41:21 -0700 (PDT) Subject: Re: [PATCH v2] mm: fix the memory leak after collapsing the huge page fails References: <1494327305-835-1-git-send-email-zhongjiang@huawei.com> <442638e9-d6db-2f1c-e260-9290d7524f1d@suse.cz> <5911B40D.2020007@huawei.com> From: Vlastimil Babka Message-ID: <0bca4592-efa5-deba-0369-19beacfd2a63@suse.cz> Date: Tue, 9 May 2017 14:41:18 +0200 MIME-Version: 1.0 In-Reply-To: <5911B40D.2020007@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: zhong jiang Cc: akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, hannes@cmpxchg.org, mgorman@techsingularity.net, linux-mm@kvack.org On 05/09/2017 02:20 PM, zhong jiang wrote: > On 2017/5/9 19:34, Vlastimil Babka wrote: >> On 05/09/2017 12:55 PM, zhongjiang wrote: >>> From: zhong jiang >>> >>> Current, when we prepare a huge page to collapse, due to some >>> reasons, it can fail to collapse. At the moment, we should >>> release the preallocate huge page. >>> >>> Signed-off-by: zhong jiang >> Hmm, scratch that, there's no memory leak. The pointer to new_page is >> stored in *hpage, and put_page() is called all the way up in >> khugepaged_do_scan(). > I see. I miss it. but why the new_page need to be release all the way. AFAIK to support preallocation and reusal of preallocated page for collapse attempt in different pmd. It only works for !NUMA so it's likely not worth all the trouble and complicated code, so I wouldn't be opposed to simplifying this. > I do not see the count increment when scan success. it save the memory, > only when page fault happen. I don't understand what you mean here? > Thanks > zhongjiang >>> --- >>> mm/khugepaged.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >>> index 7cb9c88..586b1f1 100644 >>> --- a/mm/khugepaged.c >>> +++ b/mm/khugepaged.c >>> @@ -1082,6 +1082,8 @@ static void collapse_huge_page(struct mm_struct *mm, >>> up_write(&mm->mmap_sem); >>> out_nolock: >>> trace_mm_collapse_huge_page(mm, isolated, result); >>> + if (page != NULL && result != SCAN_SUCCEED) >>> + put_page(new_page); >>> return; >>> out: >>> mem_cgroup_cancel_charge(new_page, memcg, true); >>> @@ -1555,6 +1557,8 @@ static void collapse_shmem(struct mm_struct *mm, >>> } >>> out: >>> VM_BUG_ON(!list_empty(&pagelist)); >>> + if (page != NULL && result != SCAN_SUCCEED) >>> + put_page(new_page); >>> /* TODO: tracepoints */ >>> } >>> >>> >> >> . >> > > -- 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