Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4060501pxb; Tue, 26 Jan 2021 11:17:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJy+ye6nph/pKHXbqPrOXMcY1dt8JkN+pdFTKIAD0AkBTnEHws49PYSaBUf+uirCAU3Au2As X-Received: by 2002:a05:6402:3508:: with SMTP id b8mr5785084edd.341.1611688653420; Tue, 26 Jan 2021 11:17:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611688653; cv=none; d=google.com; s=arc-20160816; b=QicQ3jJlOKH9HXmEyUxrkvbl4Z5HvTkinquXXNzEcl/gegMIAsvy8i/MKstJoiHGnO nMX0H2QkmgtWSI/HROfRAklVXql1gRUFH8FBt0bvblf8sUG6NEybCEgnu0wdEjJawITk iXrsS+c6EwCRkR1gzns2ovlktd9BuI3QQfU1Kg50Owt80u9gKPdGrJpz9I6+6FdZVaKx d+y8Z+DqQn1MtZo4AxmJiRrhKQUVCTlvO843kr6XPqKyG37KH2HjpFiCNlC8N6Dd8UKU ZRhaiqmw/2WYvBUVPHACfUhLCB1UubxNwPcFgAcz0coiiU0FDb1ZsfWddLkDZG2/11n4 hGfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Mib1480wj2H1p6hM+NvQGXudxNo2M2MPu86Zu3AnrqU=; b=hi+8DLcM69ZaPth70lg2Y8zcdNx1Qwxwe9ZIiAOxZvgSrYnk6wCGGzPSTvCD8V7yle bgmea4mMO3yn4GPVaxux3W92RCNc7SXZGqiCEishTbewna4YTR1DeJJP1J5jSiwZvl3g btYAYqgKTuyZ+AtSwZqLctS5JKQhgZV2QWUuMiaYOCcLQ138ZVM4KwfaKKfiXUpyIDTb pf7aDHoq4IYA+4/s1dIpNkq8o3DO7buELLEvfj8b16yjFUlvbglGpQPZYI9536xZxT5A B3t4VVY1naVYpM8mq+lfUvhPfLnjS3lTFV+jarTCWtRKpEr1dyfnHZPpUWZTzSZ43opm AETA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bc28si5659876edb.181.2021.01.26.11.17.08; Tue, 26 Jan 2021 11:17:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391261AbhAZO72 (ORCPT + 99 others); Tue, 26 Jan 2021 09:59:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:55792 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391635AbhAZO7J (ORCPT ); Tue, 26 Jan 2021 09:59:09 -0500 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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