From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1472CC2D0E4 for ; Tue, 24 Nov 2020 11:51:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 57E182076B for ; Tue, 24 Nov 2020 11:51:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="MIozIeOF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57E182076B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 545396B00BC; Tue, 24 Nov 2020 06:51:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CF0F6B00BE; Tue, 24 Nov 2020 06:51:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 398676B00BF; Tue, 24 Nov 2020 06:51:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 1F58D6B00BC for ; Tue, 24 Nov 2020 06:51:13 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E064B181AEF21 for ; Tue, 24 Nov 2020 11:51:12 +0000 (UTC) X-FDA: 77519145984.02.badge52_0808f842736d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id BD6FD10097AA1 for ; Tue, 24 Nov 2020 11:51:12 +0000 (UTC) X-HE-Tag: badge52_0808f842736d X-Filterd-Recvd-Size: 3421 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 11:51:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1606218671; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R7XL6NbI/L1JqsoaBbCg/8rQlfbuYPIiCpwYgPMu2mg=; b=MIozIeOFbRW5Ry015oTrsjcDq4T7mnxR+twzbUa9fIW9K/f3oqhKhlhZd+LqIaCp5Bbwdy nijaaQDw2prFGMcM7lEa8aBYf85Mkh1wJaKucPhsT2IR+O2zTI6PikuLd2ZRFHhs1JRFJl Z49fqQu/QRyT6EKdt//6TbB8p28+J3o= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 04F77ADC5; Tue, 24 Nov 2020 11:51:11 +0000 (UTC) Date: Tue, 24 Nov 2020 12:51:09 +0100 From: Michal Hocko To: Muchun Song Cc: corbet@lwn.net, mike.kravetz@oracle.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, rdunlap@infradead.org, oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, almasrymina@google.com, rientjes@google.com, willy@infradead.org, osalvador@suse.de, song.bao.hua@hisilicon.com, duanxiongchun@bytedance.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v6 09/16] mm/hugetlb: Defer freeing of HugeTLB pages Message-ID: <20201124115109.GW27488@dhcp22.suse.cz> References: <20201124095259.58755-1-songmuchun@bytedance.com> <20201124095259.58755-10-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201124095259.58755-10-songmuchun@bytedance.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 24-11-20 17:52:52, Muchun Song wrote: > In the subsequent patch, we will allocate the vmemmap pages when free > HugeTLB pages. But update_and_free_page() is called from a non-task > context(and hold hugetlb_lock), so we can defer the actual freeing in > a workqueue to prevent use GFP_ATOMIC to allocate the vmemmap pages. This has been brought up earlier without any satisfying answer. Do we really have bother with the freeing from the pool and reconstructing the vmemmap page tables? Do existing usecases really require such a dynamic behavior? In other words, wouldn't it be much simpler to allow to use hugetlb pages with sparse vmemmaps only for the boot time reservations and never allow them to be freed back to the allocator. This is pretty restrictive, no question about that, but it would drop quite some code AFAICS and the resulting series would be much easier to review really carefully. Additional enhancements can be done on top with specifics about usecases which require more flexibility. > Signed-off-by: Muchun Song > --- > mm/hugetlb.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++------ > mm/hugetlb_vmemmap.c | 5 --- > mm/hugetlb_vmemmap.h | 10 ++++++ > 3 files changed, 95 insertions(+), 16 deletions(-) -- Michal Hocko SUSE Labs