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 B098CC433E0 for ; Tue, 26 Jan 2021 15:35:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FA6F23109 for ; Tue, 26 Jan 2021 15:35:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FA6F23109 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 968398D00EE; Tue, 26 Jan 2021 10:34:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F16E8D00ED; Tue, 26 Jan 2021 10:34:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B8B78D00EE; Tue, 26 Jan 2021 10:34:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 640F38D00ED for ; Tue, 26 Jan 2021 10:34:59 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 305A93640 for ; Tue, 26 Jan 2021 15:34:59 +0000 (UTC) X-FDA: 77748324318.07.balls32_3e16c532758f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 0EED91803F9A3 for ; Tue, 26 Jan 2021 15:34:59 +0000 (UTC) X-HE-Tag: balls32_3e16c532758f X-Filterd-Recvd-Size: 3659 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 Jan 2021 15:34:58 +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 1D1B8AB92; Tue, 26 Jan 2021 15:34:57 +0000 (UTC) Date: Tue, 26 Jan 2021 16:34:52 +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: <20210126153448.GA17455@linux> References: <20210117151053.24600-1-songmuchun@bytedance.com> <20210117151053.24600-6-songmuchun@bytedance.com> <20210126092942.GA10602@linux> <6fe52a7e-ebd8-f5ce-1fcd-5ed6896d3797@redhat.com> <20210126145819.GB16870@linux> <259b9669-0515-01a2-d714-617011f87194@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <259b9669-0515-01a2-d714-617011f87194@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 04:10:53PM +0100, David Hildenbrand wrote: > The real issue seems to be discarding the vmemmap on any memory that has > movability constraints - CMA and ZONE_MOVABLE; otherwise, as discussed, we > can reuse parts of the thingy we're freeing for the vmemmap. Not that it > would be ideal: that once-a-huge-page thing will never ever be a huge page > again - but if it helps with OOM in corner cases, sure. Yes, that is one way, but I am not sure how hard would it be to implement. Plus the fact that as you pointed out, once that memory is used for vmemmap array, we cannot use it again. Actually, we would fragment the memory eventually? > Possible simplification: don't perform the optimization for now with free > huge pages residing on ZONE_MOVABLE or CMA. Certainly not perfect: what > happens when migrating a huge page from ZONE_NORMAL to (ZONE_MOVABLE|CMA)? But if we do not allow theose pages to be in ZONE_MOVABLE or CMA, there is no point in migrate them, right? > > > > 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. > > Note that we most likely soon have to tackle migrating/dissolving (free) > hugetlbfs pages from alloc_contig_range() context - e.g., for CMA > allocations. That's certainly something to keep in mind regarding any > approaches that already break offline_pages(). Definitely. I already talked to Mike about that and I am going to have a look into it pretty soon. -- Oscar Salvador SUSE L3