From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A5FE31B424F for ; Sun, 5 Apr 2026 13:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775396102; cv=none; b=J1anMWPHWmFND7AwVwo4QP4pgu3EGZAe/W4o9XPJABlU8M30xVDVPo2dr8tEfIb3x9u4iXn94k5J80QCiUCBy9IMczNQ1JXO9TwFqZWOEy4K3TgVmr6FIhz6Fmkx+wnjVX/DVlrz8D4DMm9e+EqRQtcMEK6GQrTHJxy/8tLU/ik= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775396102; c=relaxed/simple; bh=WWuKH7V5NGGgAcGyGGVsYW3h6302QQpGr0/S5xsirPA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hTSZozVIdbOpfk5g0BDs3AU6Z/wcIhuAHuj9rpctNNl07hwiHTv1boDMFI9mmUz7ftDOI3AAdjKJ6U1phGv+uV3fZ34Xhpl4lcCNqA9Izk2MUG3upKZAdnPuQ0y8rZyvCkZjEy7hes/7NwTU66gE7OvOl3W8yQw4hbjei1GiJNk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JsuR22bB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JsuR22bB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01887C116C6; Sun, 5 Apr 2026 13:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775396102; bh=WWuKH7V5NGGgAcGyGGVsYW3h6302QQpGr0/S5xsirPA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JsuR22bBOjH3ft1M/WUeMEYQAF6hTu5hn2tzOUD3fMIgLiO98o1NHa9qvmyC0jTqW sbe+mCcRvf+TA5onjzDvEDuf50nLBngm414f0zKX+a8LOQt0ODkU1gsw3Ocz0QRZ7h 7w3BsUG3WcylXg33DrqbyD0s94LPdvyCHXIsNddWSFPDM8WQqOKwwZBqpd6yI/1pVo d4Trlon650nrHqNIoA+M9we70iiCUab6u+0TayT8VqdgXNAs33scs5kHK5as06c2CL eJPPYetGQNp+OsrDK9Q3fQj5DZ7OK2esPexzi1MFaTcenmV438ealYjg5I5AWH9h5M 7cOqG8pKzar4Q== Date: Sun, 5 Apr 2026 16:34:53 +0300 From: Mike Rapoport To: Muchun Song Cc: Andrew Morton , David Hildenbrand , Muchun Song , Oscar Salvador , Michael Ellerman , Madhavan Srinivasan , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Nicholas Piggin , Christophe Leroy , aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/49] mm: Generalize vmemmap optimization for DAX and HugeTLB Message-ID: References: <20260405125240.2558577-1-songmuchun@bytedance.com> 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: <20260405125240.2558577-1-songmuchun@bytedance.com> Hi Muchun, On Sun, Apr 05, 2026 at 08:51:51PM +0800, Muchun Song wrote: > Overview: > This patch series generalizes the HugeTLB Vmemmap Optimization (HVO) > into a generic vmemmap optimization framework that can be used by both > HugeTLB and DAX. > > Background: > Currently, the vmemmap optimization feature is highly coupled with > HugeTLB. However, DAX also has similar requirements for optimizing vmemmap > pages to save memory. The current implementation has separate vmemmap > optimization paths for HugeTLB and DAX, leading to duplicated logic, > complex initialization sequences, and architecture-specific flags. > > Implementation: > This series breaks down the optimization into a generic framework: > - Patch 1-6: Fix bugs related to sparse vmemmap initialization and DAX. > - Patch 7-13: Refactor the existing sparse vmemmap initialization. > - Patch 14-26: Decouple the vmemmap optimization from HugeTLB and > introduce generic optimization macros and functions. > - Patch 27-39: Switch HugeTLB and DAX to use the generic framework. > - Patch 40-49: Clean up the old HVO-specific code and simplify it. > > Benifit: > - When CONFIG_DEFERRED_STRUCT_PAGE_INIT is disabled, all struct pages > utilizing HVO (HugeTLB Vmemmap Optimization) skip initialization in > memmap_init, significantly accelerating boot times. > - All architectures supporting HVO benefit from the optimizations > provided by SPARSEMEM_VMEMMAP_PREINIT without requiring > architecture-specific adaptations. > - Device DAX struct page savings are further improved, saving an > additional 4KB of struct page memory for every 2MB huge page. > - Vmemmap tail pages used for Device DAX shared mappings are changed > from read-write to read-only, enhancing system security. > - HugeTLB and Device DAX now share a unified vmemmap optimization > framework, reducing long-term maintenance overhead. This looks very interesting ... > 32 files changed, 513 insertions(+), 1197 deletions(-) ... and nicely cleaning up things. This series is high on my TODO list, but most likely I won't have time for proper review until after -rc1. -- Sincerely yours, Mike.