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 2B83A3D544 for ; Fri, 17 Apr 2026 12:57:36 +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=1776430660; cv=none; b=UlpNn4nZrtCD86YhojJLNKq2Uv663KAmsEpS8AV1tZUlYDywIFHEt60Fn0a7npFctL4FTDard71qyt6yzEu+tnCYSbnltUDl/DYSEPNCK3jmrzRsc6sgBfCvfCAmhe5ShxYj5Ucge/ySMf+UOdS2I3MBocmBEE3C3m7an9JEJTY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776430660; c=relaxed/simple; bh=cjGH05+drqCIjKY/6hZZ2s4i8QFh/7ky2ozVbMcm+0c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nGm7wB9cYF5QpGtuEt6pm3HGnQ0jM7OhRdhbyHLnzv+a1VqyehCju11vb/oc8v/M9hbO9sBrZmcYYAmDpID/0YbSuBq5vC0JeB65XumvoDfcsEgs2muYma7p6wYDJOjJUeVPneYM0avIU2suDaV+GdpGCwQp/m4BFrqpLrkwjWY= 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=CMhwdnQx; 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="CMhwdnQx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776430655; 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=bR2LlG2Z9OwJ3IbsfdJKwXcRLEurdguo/ZlSUV0sDIE=; b=CMhwdnQxwkA09C1SGpyvbJBS0VZEIozchpoUPcP6apPIkwb54f2uvWCsCUmGiSt5ho+c6F RLV2dIVvYxN9BtxF1zuiT0f7pzp2FWhVjv7BFPEbrPomjVfBA0qvvj6rzYAEBIkZcWCtc6 Cg6nF0Omr4grpFIFtYtbn8fcuBe1r4g= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-393-L-3xTo9jMgelen7mm8diJw-1; Fri, 17 Apr 2026 08:57:34 -0400 X-MC-Unique: L-3xTo9jMgelen7mm8diJw-1 X-Mimecast-MFC-AGG-ID: L-3xTo9jMgelen7mm8diJw_1776430654 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-8ac04b2fc4eso15933016d6.0 for ; Fri, 17 Apr 2026 05:57:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776430654; x=1777035454; 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=bR2LlG2Z9OwJ3IbsfdJKwXcRLEurdguo/ZlSUV0sDIE=; b=tE/7OwFd3zC7OW6kgsMwZ+fQYKP3oXGKi+fNfbyyS8J7TZZ+nBVu72uHl/p3h5Q8N6 tOyD6IEdaeBcGeKLkWk8w7OJ/orVoFND3ZhuT8AMyBoySvIEhmdqUujUkh3wkMxyHp6o lIsc/uABZGTwFJR+8/wCpaRC+XAniWhbxgVb3Zmbck0Rcq/d0VFUwR+zIm4S+wYfWE+p zBfTutkaEXKaDeNkLLEQ+OXTtUpdu3BNG1Yfsk/GQFIUP8f8zCDsnBOqWClcoJRz3cpy CK2b0Gh2u/Nib2ZSkAEAncdq/Af0rcJkCSaMsT2pb1h1gZIsj5OhKdER158jLrW0sysy N0jA== X-Gm-Message-State: AOJu0YwmYgPa2UQtw0VEqYPT6S2RNciVDAF9J1d9FoWnXbf1QDFqfWOp OVzaf6kwxbQr0CBfEPDqNOzrOK/IOZZlmGWMfdcwnflhDOfC0Ip07twBumsxg9n6CKaJjVqgygC eIxDTX4ZC1Pln0Lh50xy9lu5lZIE90r45NulD3oHYkkNISeH+trZ3yipOyDqIfKs5oQ== X-Gm-Gg: AeBDiesSXXrDIKKcby0T63e6gMjgZT1WWrdNHZ6T08FCB7kl1b45S3TNE8iMrT3BIWv VjfuXtgoTcwm8UHg3qsuxSh1Ph1+CFEq23/UvIpg5WuhQAW3S5jmmMhjwHkmf6uZQsFynmLQvlc XzMWF2B8qb3Qi+VfWZ3Qrlxjq/M88YqJNVgc99brBRncP85QktAb0VP4Vd42650J6YkGoRdaeQT PY2dBy1sYEygD5kpwF7WnC5cKEpMh+4TJlMO5gfLDBwj32W/avSJ3rlzaOv+quOHngC96EmRU0W 9UqQZUIVoGozy/Zqhpg0MQZAwylrtLPORJ9mV5PY7SH52FcgbcKFdms7OLlSGYGXrUyrzVN0RWy 0+08ym2Rx8rucfeKveJ6p1lg4dHwIpVxajGUc X-Received: by 2002:a05:6214:acf:b0:8ae:5fcc:8069 with SMTP id 6a1803df08f44-8b02813d122mr43680306d6.22.1776430654240; Fri, 17 Apr 2026 05:57:34 -0700 (PDT) X-Received: by 2002:a05:6214:acf:b0:8ae:5fcc:8069 with SMTP id 6a1803df08f44-8b02813d122mr43679756d6.22.1776430653673; Fri, 17 Apr 2026 05:57:33 -0700 (PDT) Received: from [192.168.2.110] ([69.159.169.238]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8b02aa4f1f9sm10565916d6.0.2026.04.17.05.57.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2026 05:57:33 -0700 (PDT) Message-ID: <988b8af9-1966-4f74-bc40-35685be7d53f@redhat.com> Date: Fri, 17 Apr 2026 08:57:22 -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 v3 02/10] mm: introduce pgtable_has_pmd_leaves() To: "David Hildenbrand (Arm)" , Lance Yang Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, ryan.roberts@arm.com, akpm@linux-foundation.org, ljs@kernel.org, ziy@nvidia.com, Liam.Howlett@oracle.com, npache@redhat.com, dev.jain@arm.com, baohua@kernel.org References: <20260410081938.51302-1-lance.yang@linux.dev> <8a0b6d67-121a-4ac8-a74b-737d52d8b7ac@kernel.org> Content-Language: en-US, en-CA From: Luiz Capitulino In-Reply-To: <8a0b6d67-121a-4ac8-a74b-737d52d8b7ac@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-04-17 05:57, David Hildenbrand (Arm) wrote: > On 4/10/26 10:19, Lance Yang wrote: >> >> On Wed, Apr 08, 2026 at 04:22:57PM -0400, 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 | 8 ++++++++ >>> 3 files changed, 24 insertions(+) >>> >>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >>> index a50df42a893f..c4c5282f795c 100644 >>> --- a/include/linux/pgtable.h >>> +++ b/include/linux/pgtable.h >>> @@ -2192,6 +2192,21 @@ static inline const char *pgtable_level_to_str(enum pgtable_level level) >>> } >>> } >>> >>> +#ifdef CONFIG_MMU >>> +extern bool __arch_has_pmd_leaves; >>> +static inline bool pgtable_has_pmd_leaves(void) >>> +{ >>> + return __arch_has_pmd_leaves; >>> +} >>> +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 1cb395dd94e4..07f2ddbf9677 100644 >>> --- a/init/main.c >>> +++ b/init/main.c >>> @@ -1044,6 +1044,7 @@ void start_kernel(void) >>> print_kernel_cmdline(saved_command_line); >>> /* parameters may set static keys */ >>> parse_early_param(); >>> + init_arch_has_pmd_leaves(); >> >> One more thought here: I don't see why we need boot-time caching. >> >> has_transparent_hugepage() does *not* look expensive on the common >> archs. On x86, it is just a CPU feature check. MIPS is different, yes, >> only the first call there is more involved ... >> >> But if we *really* want caching, couldn't we just do it lazily instead >> of adding another early boot init step? >> >> Something like: >> >> bool pgtable_has_pmd_leaves(void) >> { >> static int __arch_has_pmd_leaves = -1; >> >> if (READ_ONCE(__arch_has_pmd_leaves) < 0) >> WRITE_ONCE(__arch_has_pmd_leaves, has_transparent_hugepage()); >> >> return READ_ONCE(__arch_has_pmd_leaves); > > Would look easier when just using two booleans: "has_pmd_leaves" and > "probed". > > I do like static keys, though. And wonder whether just putting that into > hugepage_init() would be sufficient? Do you mean the static key initialization? I think it's sufficient today, but we'd be tying the new API to THP and the initialization ordering still occurs although it's indirect.