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 ED66B4B8DCF for ; Wed, 6 May 2026 17:50:57 +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=1778089862; cv=none; b=QvV9TDI7AGHf10JB89LwceCJAuSSUVAGzt6ZUvIYieChPs92LTfsLHfAinYBES9Jhd+6GLbNL803q4JWuYPkTRDUzVUYkHkFmT/Btr+asNFVGmpNT5+hBKF1tg5uvb1gvzSOMJLPFnSPGlu1iIe0f+3TtTei6rvwkHNGwKpBHgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778089862; c=relaxed/simple; bh=vmaNs49yUos616ntMkd/qxaj5OR9ZeoqJOe8GLU+qdM=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=KlidKhdSd69XnVQ3DdUxqFKEVY9n/LOW51ltxZn9+rvZkqUra7dco6v2qAvin4y9k9yBYSa5dMju3BFMjD00ekhptK+7fLzPUWtOorX3mX8R+pEi4AX7idAfismEym+rj2feJhO1pVqQdCXjBlPZIkq/1OQYvFNHnHq3/oxWrL8= 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=PkcnXM9X; 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="PkcnXM9X" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778089855; 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=eggJN5NeK5KdcWJHIvN10Zh1zzswDtzrYj+onxzIjDc=; b=PkcnXM9X+6ZiTcsgrCFUipMQnRLHrDTWwVPU7eas0wKV/NcVQMEHbmCo7DEoZhGC6EyEOm r83EwaibfrXndnhbY2FvQbtKqKA/qX111o63kMFCJDh16U7LIhhst/06RCcdj7q6jFew6Q aXbOymN5uKXzzw0GULfoxlZgsDGrreo= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-457-XHyYC1lONF-xoj7p13TXxQ-1; Wed, 06 May 2026 13:50:54 -0400 X-MC-Unique: XHyYC1lONF-xoj7p13TXxQ-1 X-Mimecast-MFC-AGG-ID: XHyYC1lONF-xoj7p13TXxQ_1778089854 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8eacc2008b2so1308253085a.3 for ; Wed, 06 May 2026 10:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778089852; x=1778694652; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from: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=eggJN5NeK5KdcWJHIvN10Zh1zzswDtzrYj+onxzIjDc=; b=KkRkup9V+dDw/jCiUF5j/x7Bn5yUOFuLT4RZfOxtBJX6rH2gd8Rh50rdTF4Sn3qFM+ dy3Ek9MIwZhaLXjXOZy6j+1+1FxFgeNWZPhpdZlpnc88uel/YI6IzmT60C7kNasr2Zrn 8ezS3CA1eDtxraXkdM+yB02sNtVt7kjYNYiFb7t3VAZQqLrfDxhVmSGPyPUgxOY+duc7 FNzNUWdzNLeCbM4M317dSKf/cU6G+edHLHELDmGDc1VlP0uQCqXaVf0GRTSNXHUwB1Hd eo5O0DzHDEIC5660vjyxMesYWLUVx5TMoDnwAp0rUhhIjXA0ULr6nPOaHtAYN8N1DHZ9 GOpg== X-Gm-Message-State: AOJu0YwZ1NANYc2oQuz5y/ZoPvoZ7MUrlj1pTP+2N/9gWrxWsEX3FBU1 kYn+8xMqngYYe6spz3isj6Om/ITWbmuuuA5/U+FfLCao2VUzPRHPbNRG0bdRFOnVy23k7Rr5OD2 b98PCLPGnO/NXQcQjdxO8B+s30wZkt/I1curG1rqefqQtuE6c8Xeqxx3fcg9gG/Wb6nM9Vjzp4m rXioHa/SVa4lfd1hQcr3JMLEAGmQVpSMU5sQcDARlMYxTYrRKpsjY= X-Gm-Gg: AeBDietalT5IScgmVMSx5Zzh80jsXAxlk+Ueh4AV2MjxbljvY2e1rruolRvZp6sPsVm l70IC5BqV8vo2m8D64wjcvqP3SDIpqmAyRdvh2i5UYiDGUfKwXl4VdlSc6zXM7yNWspoMeHEi0z iwAPt4cJ89yi1UlHzuMcRH58ZtHD14Gkh04h6062XJHHtA8swIVIT519r6L2wZJAKE0ee5I8q/5 n6t//KBnf4AUvm5eXu3xyQEm5YRoY47VqzN0+QOuCW1n4MysQFTZf298KoFpzRt9H7f9Pe8ZIDV mzPH7gbYNmpwMfCsmA22K0zpXxu5Uua/QLNfzjRID98nDFvzxOros26+AEwnJWapZS9Ii1oouBa oiQICkAV3kkaOwm7MGv5562QKPbvCqBZWrrg= X-Received: by 2002:a05:620a:a2d3:10b0:904:f2cf:f1ff with SMTP id af79cd13be357-904f2cff262mr446159985a.62.1778089851948; Wed, 06 May 2026 10:50:51 -0700 (PDT) X-Received: by 2002:a05:620a:a2d3:10b0:904:f2cf:f1ff with SMTP id af79cd13be357-904f2cff262mr446150385a.62.1778089851032; Wed, 06 May 2026 10:50:51 -0700 (PDT) Received: from [192.168.2.110] ([70.53.202.134]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8fc2c91cd7dsm1688336485a.37.2026.05.06.10.50.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2026 10:50:50 -0700 (PDT) Message-ID: <4cb079c7-c6ed-435d-849f-5828dcdbfda0@redhat.com> Date: Wed, 6 May 2026 13:50:39 -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: (sashiko review) Re: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves() From: Luiz Capitulino To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, david@kernel.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> Content-Language: en-US, en-CA In-Reply-To: <2a0bae00cdd2b6ef6b962610b523ebfc97806ba7.1777663129.git.luizcap@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-05-01 15: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); """ This adds DECLARE_STATIC_KEY_TRUE and static_branch_likely but doesn't explicitly include linux/jump_label.h. Can this cause build breakages in compilation units that include linux/pgtable.h but do not have linux/jump_label.h in their dependency chain? """ I've built this series for a few archs and I'm sure the kernel bot built it too, so I'd assume this is not an issue. But since adding the header doesn't hurt, I can do it. > +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(); > after_dashes = parse_args("Booting kernel", > static_command_line, __start___param, > __stop___param - __start___param, > diff --git a/mm/memory.c b/mm/memory.c > index ea6568571131..90b2d9e84320 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -164,6 +164,15 @@ __setup("norandmaps", disable_randmaps); > > unsigned long highest_memmap_pfn __read_mostly; > > +DEFINE_STATIC_KEY_TRUE(__arch_has_pmd_leaves_key); > +EXPORT_SYMBOL(__arch_has_pmd_leaves_key); > + > +void __init init_arch_has_pmd_leaves(void) > +{ > + if (!has_transparent_hugepage()) > + static_branch_disable(&__arch_has_pmd_leaves_key); > +} > + """ Will this unconditionally disable the static key when CONFIG_TRANSPARENT_HUGEPAGE is not enabled, since has_transparent_hugepage() evaluates to 0 in that configuration? This seems to contradict the commit message's goal of decoupling the hardware capability check from THP enablement. I see this is fixed later in the patch series in commit 4782375d13da ("treewide: introduce arch_has_pmd_leaves()"), but could this cause regressions for non-THP PMD users if they test at this point in the series? """ There's no users of the new API in this patch and all converted users in the following patches are protected by #ifdef CONFIG_TRANSPARENT_HUGEPAGE so it's not an issue. > void mm_trace_rss_stat(struct mm_struct *mm, int member) > { > trace_rss_stat(mm, member);