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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 4E137C433DB for ; Thu, 28 Jan 2021 22:29:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F80B64DF8 for ; Thu, 28 Jan 2021 22:29:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F80B64DF8 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 E5F316B006C; Thu, 28 Jan 2021 17:29:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DE7386B0070; Thu, 28 Jan 2021 17:29:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAF5B6B0071; Thu, 28 Jan 2021 17:29:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id B2BD16B006C for ; Thu, 28 Jan 2021 17:29:13 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7F74C180AD837 for ; Thu, 28 Jan 2021 22:29:13 +0000 (UTC) X-FDA: 77756625786.10.alley91_5203562275a3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 5A39116A0DE for ; Thu, 28 Jan 2021 22:29:13 +0000 (UTC) X-HE-Tag: alley91_5203562275a3 X-Filterd-Recvd-Size: 3927 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Jan 2021 22:29:12 +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 C239FAC60; Thu, 28 Jan 2021 22:29:10 +0000 (UTC) Date: Thu, 28 Jan 2021 23:29:06 +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: <20210128222906.GA3826@localhost.localdomain> 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> <20210126153448.GA17455@linux> <9475b139-1b33-76c7-ef5c-d43d2ea1dba5@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 27, 2021 at 11:36:15AM +0100, David Hildenbrand wrote: > Extending on that, I just discovered that only x86-64, ppc64, and arm64 > really support hugepage migration. > > Maybe one approach with the "magic switch" really would be to disable > hugepage migration completely in hugepage_migration_supported(), and > consequently making hugepage_movable_supported() always return false. Ok, so migration would not fork for these pages, and since them would lay in !ZONE_MOVABLE there is no guarantee we can unplug the memory. Well, we really cannot unplug it unless the hugepage is not used (it can be dissolved at least). Now to the allocation-when-freeing. Current implementation uses GFP_ATOMIC(or wants to use) + forever loop. One of the problems I see with GFP_ATOMIC is that gives you access to memory reserves, but there are more users using those reserves. Then, worst-scenario case we need to allocate 16MB order-0 pages to free up 1GB hugepage, so the question would be whether reserves really scale to 16MB + more users accessing reserves. As I said, if anything I would go for an optimistic allocation-try , if we fail just refuse to shrink the pool. User can always try to shrink it later again via /sys interface. Since hugepages would not be longer in ZONE_MOVABLE/CMA and are not expected to be migratable, is that ok? Using the hugepage for the vmemmap array was brought up several times, but that would imply fragmenting memory over time. All in all seems to be overly complicated (I might be wrong). > Huge pages would never get placed onto ZONE_MOVABLE/CMA and cannot be > migrated. The problem I describe would apply (careful with using > ZONE_MOVABLE), but well, it can at least be documented. I am not a page allocator expert but cannot the allocation fallback to ZONE_MOVABLE under memory shortage on other zones? -- Oscar Salvador SUSE L3