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 350B328727A for ; Tue, 2 Dec 2025 10:53:04 +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=1764672787; cv=none; b=VH3rkFoAoUTvw+1DPFf43uOq9EWtFKuqB4/+kB1zLsxuMRIgaVQFLwf2Z11mz/s/8uTkz4zACRzRRC3q6HJtbkec5JxMc//uhHRIKQvmFU/9htTxvb3xNy7uZH+NbSWySqrI2xiuNtT8grMezejcUr+njnJvVdrDjxHV7gPDAt0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764672787; c=relaxed/simple; bh=OmPhH3HhvCNMCbQikthtJxXqV7Wt3ktwIhlSZKtLviA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jbxX3Dr/nyj21zZmDiy6/gw5Cv/Y2BFpENyNaawh5+kmaLxhcKWMLVkUsUxDTV5ZiKg4q39aVB8coOQ9YHZgb/ziFPdchV6DEb8pZ+a0wvYJ0xDUJg0abmErhdnpyouu6FEeTabwPXZzWUfV+wwCenKhJ+/m8xlJUoWoST9Gmbc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nYZG/0Sd; 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="nYZG/0Sd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4148BC4CEF1; Tue, 2 Dec 2025 10:53:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764672784; bh=OmPhH3HhvCNMCbQikthtJxXqV7Wt3ktwIhlSZKtLviA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nYZG/0SdCZRgG4uvlJTsEuJyC8NWpZfbvUW3z/YFwXvUys51Bx9c7OgkM+0kusk7k /GWeRZ+yI+FOE5EB3F8xFCX/87WBRT5HIfVwPQ8AWHk61CXT6esZdCsCGy1Kh77xG+ U/vpxtbecXmK9aNP58mwCMEGtjHpRu9nR5g0g3QIaFD/EvOZbM2p4RWKdLAlR6pqux 9/SgFYLeVpOqTA7DJnW72h6EHMhHTUEBOwuRsA5Yzn2pwA6+MA0k0X2llYnjzmFg4N 728cDxeb7oy7V7DgbMKPurjKeeu4Flj+/WjKhCqo7G7ewWFWxNMU+h+gD1Ij0V9p6G +xTMUhlPnIscw== Message-ID: <3fcce19e-ed78-4b83-bbdd-e925a74091b2@kernel.org> Date: Tue, 2 Dec 2025 11:53:01 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 07/10] treewide: rename has_transparent_hugepage() to arch_has_pmd_leaves() To: Luiz Capitulino , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: ryan.roberts@arm.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com References: <9b56da53df2f0da40be68de9a7208d527b144afa.1762464515.git.luizcap@redhat.com> <65b0c614-e6a9-4535-9d30-bd2be7a72149@redhat.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <65b0c614-e6a9-4535-9d30-bd2be7a72149@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/17/25 20:01, Luiz Capitulino wrote: > On 2025-11-17 12:45, David Hildenbrand (Red Hat) wrote: >> On 06.11.25 22:28, Luiz Capitulino wrote: >>> Now that the majority of has_transparent_hugepage() callers have been >>> converted to pgtable_has_pmd_leaves(), rename has_transparent_hugepage() >>> to arch_has_pmd_leaves() since that's what the helper checks for. >>> >>> arch_has_pmd_leaves() is supposed to be called only by >>> init_arch_has_pmd_leaves(), except for two exeptions: >>> >>> 1. shmem: shmem code runs very early during boot so it can't use >>> pgtable_has_pmd_leaves() >> >> Can't we just initialize pgtable_has_pmd_leaves() earlier then? > > I can look into doing that. When I worked on this RFC I wondered if > arch_has_pmd_leaves() (when implemented by the arch) could run so early > given that some (all?) archs check feature bits so they must be > available this early as well. But I'll check this, having > pgtable_has_pmd_leaves() being available as early as possible is > probably the right thing to do. > >>> 2. hugepage_init(): just a temporary exception, this function will be >>> converted in a future commit >>> >>> Signed-off-by: Luiz Capitulino >>> --- >> >> >> [...] >> >>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >>> index e4c5f70b0a01..02a2772ec548 100644 >>> --- a/include/linux/pgtable.h >>> +++ b/include/linux/pgtable.h >>> @@ -2026,8 +2026,8 @@ static inline bool pgtable_has_pmd_leaves(void) >>> #endif >>> #endif >>> -#ifndef has_transparent_hugepage >>> -#define has_transparent_hugepage() IS_BUILTIN(CONFIG_TRANSPARENT_HUGEPAGE) >>> +#ifndef arch_has_pmd_leaves >>> +#define arch_has_pmd_leaves() IS_BUILTIN(CONFIG_TRANSPARENT_HUGEPAGE) >>> #endif >> >> Ah, so it stays for now only set with CONFIG_TRANSPARENT_HUGEPAGE. I guess that's something to sort out later :) > > I suggested something we could do in this series. Also, I skipped > commenting on all the cases you spotted as I think they refer to the > same issue (please, do point out if you think I'm wrong). Right. If we keep PMD-leave support glue to CONFIG_TRANSPARENT_HUGEPAGE in this series, could we also simplify patch #2, to have it reside in mm/huge_memory.c ? Then, it's clearer that it is still glued to CONFIG_TRANSPARENT_HUGEPAGE. -- Cheers David