From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 4880C824A3 for ; Thu, 14 May 2026 01:52:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778723542; cv=none; b=jPFx6dHFOMPFGnYCJMASKvu+j3g8dt/LfpPfoe2VAUZ6b6jwXh5SFv/f5r2LfEUm1TufgOB7a5JkFZJMZUbJukBiwessBelDGg6iKrcVLwxFzK2KYDDr2V0R68fWNBfiYicFCXjzlvzR4LKOn0DMYSVOJS8rdvnV4QlvbBVfuvE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778723542; c=relaxed/simple; bh=9QqIOV7Wjr9+8ce1SWAY0DYrrLKcA1vQ1jlnja8Os2s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=TohaFNNTIr17TTf9yMblu97FUOqzifD/kI3UztDQXKsKie+fvcXOn+miK6pqAqX1f544512qLxyiKSjSxAgLT2G0b817kxKnw0MkbSQJwFpJv9G4AjaiwNW60W+xdtK6PBFCO3CLqOPNgg23V551LIWpSC/HoIqXg+9ODsRrrr0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=MP6FJLdA; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MP6FJLdA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778723539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5nvZWCIe8eIErP8hr8TwPvr6Up6QixBNDg3fotBUjkw=; b=MP6FJLdAb+aMkqDiQhFbEqdE6yNgUm7ozwMyzgSNoG2ELaXtXXKUZ3Hv4r9kXLlzMWzuUT zKqgCVwpZjT/7FV6PQ7sf1ISKIzI41FsAfjw3kI5bIk66PoL3KPEaT3gp1u6fmwAAZ5Axf 7kgZcvxqLg+9J50uwsHOVGsM2Yb7kkY= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-53-SIbd3oXgMim9yO44GOTLaw-1; Wed, 13 May 2026 21:52:18 -0400 X-MC-Unique: SIbd3oXgMim9yO44GOTLaw-1 X-Mimecast-MFC-AGG-ID: SIbd3oXgMim9yO44GOTLaw_1778723537 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-5104b861649so226644541cf.1 for ; Wed, 13 May 2026 18:52:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778723537; x=1779328337; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5nvZWCIe8eIErP8hr8TwPvr6Up6QixBNDg3fotBUjkw=; b=BxE5TnLhcbniuGR68kMyDUWBIYFjFYss6xYhDNcC4MatF1AzfsAU2/n/3aXOtA57gl 584+ohHG2+aa0wdH538e51Li9wEQvdrN3z8ec2QnIia3bipFSUl2PAeCmNzC/RuuJl3a mjE76qvA1gCciFf0Y4Hx0fflx6Fi1H182D6krgVvFvDe5Yhd9kcnnhI7tYXj0BGvSg/Q K5qc99ZefDVhgBBiqgYO3E06yvnUkJWWcb4q2nvgkAgtSlkiNLu+ewscWyayMJ6hyp0A kByLU0TCN6uUpysPqD0zWQ0UaS9tmD7SUHaBvcPJ7kUkO0i1oqvyp7AjIkAEPGtaWjjH KI6g== X-Forwarded-Encrypted: i=1; AFNElJ/HY7zRT/8FobqtBppYOT6NaWfM7N/r4/hpeTXS0jkKE2lYf/1BcA3UTGRZQW+mnoZ8a6kZ4X2uH3KWhpQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzQRYPX5tfWSEUeRcvonL0I2Wv3n7jHoulI8F9lpjYec3A7Sa53 GTyx6kI+ShNfmlqWk6u1zSAb163tLAibc0BY+t1SKPZJLtN8wpmoOJWo+QPFf5SAptOdF57Wvsb 74wNTO3ksEGRN3zSkc3CgCV0/nwGfA+t18rAmmctIcpXfd6QwXTwiBOX27T5X9ccDpA== X-Gm-Gg: Acq92OHU7x5SrL3w993W/Gc8kI2xwoU2SwzSTmjdUYZq5SIeqwMRRlmsxZc7KG37MG0 TmiQGuMw+x9OoRsnJG5EgVrKKgcMTCKfiTrl/kgxwbIniUJRBHHTNqZmjN8rA2ZWj2IXFxs3Vao q7NeH1LjgnQjlhoS3nEJtzI2v1HFcIV0Ll1sxl0YuooS6lnCxsuljhX8en9UavEVo3ZckmIpqrt fKkEkH5UVmYx0d98XvCwUWI7dKWfOzSSubdQqZAeuWTsoXshnjgkCK/pq+FleBB1TKnYl6p4eDK xq2/lFnfVXPAWA8noHYh24miX2Fh20GSkeopeX6nUpy5ok8tepiZgQTUqUsr4xP+ccxwEh5F8PO Ii8Gnjx6bmXMtK0H94bGT802i X-Received: by 2002:ac8:588e:0:b0:50d:8389:c3f3 with SMTP id d75a77b69052e-5162f66b122mr82858921cf.54.1778723537408; Wed, 13 May 2026 18:52:17 -0700 (PDT) X-Received: by 2002:ac8:588e:0:b0:50d:8389:c3f3 with SMTP id d75a77b69052e-5162f66b122mr82858731cf.54.1778723536896; Wed, 13 May 2026 18:52:16 -0700 (PDT) Received: from [192.168.2.110] ([70.53.202.134]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51645d51f06sm4342921cf.19.2026.05.13.18.52.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2026 18:52:16 -0700 (PDT) Message-ID: <8d365dfa-98e0-478b-ba6b-377c939865d4@redhat.com> Date: Wed, 13 May 2026 21:52:05 -0400 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: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves() To: "David Hildenbrand (Arm)" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, ziy@nvidia.com, lance.yang@linux.dev Cc: corbet@lwn.net, tsbogend@alpha.franken.de, maddy@linux.ibm.com, mpe@ellerman.id.au, agordeev@linux.ibm.com, gerald.schaefer@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com, x86@kernel.org, dave.hansen@linux.intel.com, djbw@kernel.org, vishal.l.verma@intel.com, dave.jiang@intel.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com References: <2a0bae00cdd2b6ef6b962610b523ebfc97806ba7.1777663129.git.luizcap@redhat.com> <8683a04e-54e9-4e8e-8931-69e31d15b99b@kernel.org> Content-Language: en-US, en-CA From: Luiz Capitulino In-Reply-To: <8683a04e-54e9-4e8e-8931-69e31d15b99b@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-05-13 11:30, David Hildenbrand (Arm) wrote: > On 5/1/26 21:18, Luiz Capitulino wrote: >> Currently, we have two helpers that check for PMD-sized pages but have >> different names and slightly different semantics: >> >> - has_transparent_hugepage(): the name suggests it checks if THP is >> enabled, but when CONFIG_TRANSPARENT_HUGEPAGE=y and the architecture >> implements this helper, it actually checks if the CPU supports >> PMD-sized pages >> >> - thp_disabled_by_hw(): the name suggests it checks if THP is disabled >> by the hardware, but it just returns a cached value acquired with >> has_transparent_hugepage(). This helper is used in fast paths >> >> This commit introduces a new helper called pgtable_has_pmd_leaves() >> which is intended to replace both has_transparent_hugepage() and >> thp_disabled_by_hw(). pgtable_has_pmd_leaves() has very clear semantics: >> it returns true if the CPU supports PMD-sized pages and false otherwise. >> It always returns a cached value, so it can be used in fast paths. >> >> The new helper requires an initialization step which is performed by >> init_arch_has_pmd_leaves(). We call init_arch_has_pmd_leaves() early >> during boot in start_kernel() right after parse_early_param() but before >> parse_args(). This allows early_param() handlers to change CPU flags if >> needed (eg. parse_memopt() in x86-32) while also allowing users to use >> the API from __setup() handlers. >> >> The next commits will convert users of both has_transparent_hugepage() >> and thp_disabled_by_hw() to pgtable_has_pmd_leaves(). >> >> Signed-off-by: Luiz Capitulino >> --- >> include/linux/pgtable.h | 15 +++++++++++++++ >> init/main.c | 1 + >> mm/memory.c | 9 +++++++++ >> 3 files changed, 25 insertions(+) >> >> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >> index cdd68ed3ae1a..b365be3516bf 100644 >> --- a/include/linux/pgtable.h >> +++ b/include/linux/pgtable.h >> @@ -2243,6 +2243,21 @@ static inline const char *pgtable_level_to_str(enum pgtable_level level) >> } >> } >> >> +#ifdef CONFIG_MMU >> +DECLARE_STATIC_KEY_TRUE(__arch_has_pmd_leaves_key); >> +static inline bool pgtable_has_pmd_leaves(void) >> +{ >> + return static_branch_likely(&__arch_has_pmd_leaves_key); >> +} >> +void __init init_arch_has_pmd_leaves(void); >> +#else >> +static inline bool pgtable_has_pmd_leaves(void) >> +{ >> + return false; >> +} >> +static inline void __init init_arch_has_pmd_leaves(void) { } >> +#endif >> + >> #endif /* !__ASSEMBLY__ */ >> >> #if !defined(MAX_POSSIBLE_PHYSMEM_BITS) && !defined(CONFIG_64BIT) >> diff --git a/init/main.c b/init/main.c >> index 96f93bb06c49..eea7c5bdddf7 100644 >> --- a/init/main.c >> +++ b/init/main.c >> @@ -1053,6 +1053,7 @@ void start_kernel(void) >> print_kernel_cmdline(saved_command_line); >> /* parameters may set static keys */ >> parse_early_param(); >> + init_arch_has_pmd_leaves(); > > Can't we do this a bit later from some mm code? > > This feels like something that can just go somewhere into mm_core_init()? Yes, this can be done. My intent in calling it as early as possible was to allow callers to use the API from __setup() handlers if needed, but since we don't have this case in the code today we can put it in mm_core_init() for now. > There, we should probably call this something like XXX_init(), and prepare it > from detecting support for PUD leaves as well. > > Maybe just > > pgtable_init() ? What about pgtable_api_init()? I'm afraid that pgtable_init() might be confused with code doing real page table initialization.