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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 EE055C433DB for ; Tue, 26 Jan 2021 14:58:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6633B22D58 for ; Tue, 26 Jan 2021 14:58:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6633B22D58 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CFC638D00D6; Tue, 26 Jan 2021 09:58:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CAC168D00B0; Tue, 26 Jan 2021 09:58:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4D0E8D00D6; Tue, 26 Jan 2021 09:58:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 9F5D28D00B0 for ; Tue, 26 Jan 2021 09:58:29 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6DD5F8249980 for ; Tue, 26 Jan 2021 14:58:29 +0000 (UTC) X-FDA: 77748232338.29.push65_0a09f042758f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 440B818085CEB for ; Tue, 26 Jan 2021 14:58:29 +0000 (UTC) X-HE-Tag: push65_0a09f042758f X-Filterd-Recvd-Size: 2970 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 Jan 2021 14:58:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5FA2DAB9F; Tue, 26 Jan 2021 14:58:27 +0000 (UTC) Date: Tue, 26 Jan 2021 15:58:19 +0100 From: Oscar Salvador To: David Hildenbrand Cc: Muchun Song , 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, mhocko@suse.com, song.bao.hua@hisilicon.com, naoya.horiguchi@nec.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 v13 05/12] mm: hugetlb: allocate the vmemmap pages associated with each HugeTLB page Message-ID: <20210126145819.GB16870@linux> References: <20210117151053.24600-1-songmuchun@bytedance.com> <20210117151053.24600-6-songmuchun@bytedance.com> <20210126092942.GA10602@linux> <6fe52a7e-ebd8-f5ce-1fcd-5ed6896d3797@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6fe52a7e-ebd8-f5ce-1fcd-5ed6896d3797@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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, Jan 26, 2021 at 10:36:21AM +0100, David Hildenbrand wrote: > I think either keep it completely simple (only free vmemmap of hugetlb > pages allocated early during boot - which is what's not sufficient for > some use cases) or implement the full thing properly (meaning, solve > most challenging issues to get the basics running). > > I don't want to have some easy parts of complex features merged (e.g., > breaking other stuff as you indicate below), and later finding out "it's > not that easy" again and being stuck with it forever. Well, we could try to do an optimistic allocation, without tricky loopings. If that fails, refuse to shrink the pool at that moment. The user could always try to shrink it later via /proc/sys/vm/nr_hugepages interface. But I am just thinking out loud.. > > Of course, this means that e.g: memory-hotplug (hot-remove) will not fully work > > when this in place, but well. > > Can you elaborate? Are we're talking about having hugepages in > ZONE_MOVABLE that are not migratable (and/or dissolvable) anymore? Than > a clear NACK from my side. Pretty much, yeah. -- Oscar Salvador SUSE L3