From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FF9D31D366 for ; Thu, 13 Aug 2026 10:45:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786617960; cv=none; b=Jn6MJ8mZWsPk2cH7RqjzXfqCdJsmrmti5/V736gWmBynqE3pKOBi4kQWDr3Jzh1iVKc0vDZGxLvQDWCLJ2nNkP5f/VngNSomeIwe4XbbQ5B2eSFDayhz1FLnyx2GwJn8AzAc2X17A/fWaYKzyZDDD7p4vZLsYxVJiHb+xWX573M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786617960; c=relaxed/simple; bh=po/YHO9Ig1q959aB3IKI/9S0VNYhNe1vZHy3oTyOUVY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pZy4rp2vLROYlC64FmUfaSNe6eYy1dkyqSmQZkC+5Madz5a6+W1se5ueINotaGzSpEzka/IFkpjoaLoytlkIf1/U4k6BFSAOq8M3x4q5KZEgymlVqXg4/NWdyVtj6LShCZoLEB4JAPGRz6+gza3qLAm6tw+pqUMYDOZ+X3LyDqc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VSsOJMIn; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VSsOJMIn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AE3F1F000E9; Thu, 13 Aug 2026 10:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786617958; bh=k3ZT8E7hO3bd7VzvapxR7vDSSiOWry1NDeNwNsSPfs8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VSsOJMInFBGIFRG0LXurwe7jOywCBja5t41egKLBUhAp7aS2DLGX+oPmHUrzbJBl4 PbcUTFASInRFlRz77x+CHY5UvMReAnil2f9aHwRdHdzgH0UiV5yng1vw1mQ7vWY8iE jfhaGGQxQDjWnJg0NXqGn0araFADV+vqS8/Za6mMPcJiTMaiX7mKFpOjsBGDlOCGXa CJLnHvhe+n1swRrmVDRgbccdZpPJngOSSHv03+UARVfh1qTdZPmF4DAN1nrDlAMQvW hhl4LgQewSVgW5tLmnReIf3VlLmGq4Mn0VcNOGKTPvVQKDB7OccB652enQ0hX2nlVm jX0hcadxrAuqA== Date: Thu, 13 Aug 2026 11:45:34 +0100 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Zi Yan , Qi Zheng , akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, muchun.song@linux.dev, osalvador@suse.de, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, baoquan.he@linux.dev, youngjun.park@lge.com, peterx@redhat.com, usama.arif@linux.dev, willy@infradead.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: Re: [RFC PATCH 0/8] Introducte Reserved THP Message-ID: References: <89837004-b5c9-4b59-b795-3b79005379af@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89837004-b5c9-4b59-b795-3b79005379af@kernel.org> On Thu, Aug 13, 2026 at 12:00:30PM +0200, David Hildenbrand (Arm) wrote: > ... digging through old mail. > > > > > You mean the reservation should be done via some file handle, like > > memfd, so that it is easy to apply memory policies to determine where > > reserved memory locates? > > > > For existing hugetlb reservation, there is no fine control, like NUMA, > > or cgroup, of the reserved free memory. > > > > Is that what you mean above? > > I guess, it's all tricky. hugetlb reservation is a mess. We better not make > similar mistakes with THPs. > > [...] > > >>> 3.6 Remove Hugetlb > >>> ------------------ > >>> > >>> Once reserved THP can completely replace the existing functions of hugetlb, we > >>> can gradually remove Hugetlb, leaving only one huge page management system in > >>> the kernel. > >> > >> I'm sorry, but no way this will work in any reasonable timeframe unless you > >> mimic the exact user facing ABI -- and I don't think we'll gain a lot that way. > >> > >> I know, we all like to dream, but this just isn't feasible. > > > > Based on my understanding, the key takeway is that we want to have more > > control over reserved memory, where to get the free memory, who gets how > > much of the reserved memory, and more. > > yes, it's all very complicated. Slapping on some MADV_RESERVED_THP is just > entirely the wrong way to tackle this. I agree with David that this series is a no-go, and there are many levels of complexity here: - What does reservation really mean in a context where any process can indicate desire for THP huge pages through MADV_HUGEPAGE or more big-hammer-ly MADV_COLLAPSE? Let alone mapping in THP-aligning file system's files or edge cases like DAX or soon, huge pfn mappings once I do that series. - There's no sense of ownership, and as David says NUMA makes everything more complicated. And that's before we even get on to memcg. - We have a flaming trashpile of a codebase that needs improving. There are (thankfully) efforts afoot on this front, but big new shiny features are as far as I am concerned on pause until technical debt is paid down _anyway_. - We have a flaming trashpile of an API which we must keep intact despite it having many contradictions, edge cases and points of confusion. I mean the list goes on. Also it feels like reservation is almost throwing up our arms and giving up on improving compaction which is part of the problem here - stalls have been seen in real world use cases with even /sys/kernel/mm/transparent_hugepage/defrag set to madvise let alone anything else - and I feel are part of why people want ways around things. I also think the idea of reserved memory flies in the face of THP on principle - the 'T' stands for transparent :) but in general, as David says, hugetlb is a horror show and a terrible maintenance headache (look at the recent hugetlb hw poison stuff for an example of this), and mimicing anything it does is already a dangerous road to take. As usual we keep coming back to the same broader points: - How to control the resource that is large folios in a sensible way that allows some semblence of control over this. - Do we want to give more control or be more automatic? How do we achieve a balance and what metrics should we use? - How do we even accurately measure all of this? - and let's improve compaction/migration :) These are all bikeshed-able, lead to endless discussions and I think are fruitless at this stage - right now we have a mess, firstly let's improve that mess and establish some foundations to build on iteratively. I am really rather against big concept stuff in THP to be honest and more in favour of small, incremental _improvements_ to what we already have. And feature-wise, 1 GiB THP is on the horizon and as David says figuring that out sensibly should be instructive. But notice that Usama has been providing various foundational series (like the huge swap stuff) to establish this. So Tl;DR - let's be incremental, cautious, and improve this damn codebase before we even think of larger changes. > > -- > Cheers, > > David -- Cheers, Lorenzo