From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (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 47B1313B7AE for ; Mon, 20 Apr 2026 06:56:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776668188; cv=none; b=Kd98RKnCyhq+J/Blfy1eNdiTAAT8s/eWP5RUEh5lggdKcDb1tqcUJsCRtO6JaooN+q4/LBjp+MT1ct5gmhwvB4Zz8kKpQK3M9XwHimMRFCo7wKi+ibXDWQmyWQoJAyE82yjXO07xRKunHgguUkWcLB48iWdXVVJb1fEGSX74448= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776668188; c=relaxed/simple; bh=MTjOatCoBjqmPiAIcdh1fYp4OtxBWDvbjasWys/UFKA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=lroKe8ZA0bfIOJBpwL4O7EnwHCgvw+q+GVgyoACGXWLK71Bl6/BMphLirrhe+q2XK5idoF/OOCo3G1y/BhLZFhaqKYv64zfw0lxPznUib8dQQLjNjFfCQHKHBGvzYNjq6vF59NpzVFdBqBxv1wRu9yeT/AgBsGFHn2d3IFw8z4k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=tlGk+B6c; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="tlGk+B6c" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776668184; 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=xGsb+8op9HfuZM90V1dqEvT2Pz/EwuZxxHDEbjQ1P60=; b=tlGk+B6cD2wQoxeTxTQaIM9HgJG1/fOl+TD439S2eSzteQIBtVQoF/qt0Tj5ipd2lKSyoK a2eSdPyMUV2erR1RW8e8FhTveArdfnfmsDUDnpn9TBMKphzzrr6xeUo9Gzw4+q5jECH65z bKOrgBaU6HAeQpddApi0I5zgE6b3f1U= From: Lance Yang To: david@kernel.org Cc: lance.yang@linux.dev, luizcap@redhat.com, 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 Subject: Re: [PATCH v3 02/10] mm: introduce pgtable_has_pmd_leaves() Date: Mon, 20 Apr 2026 14:55:56 +0800 Message-Id: <20260420065556.74028-1-lance.yang@linux.dev> In-Reply-To: <8a0b6d67-121a-4ac8-a74b-737d52d8b7ac@kernel.org> References: <8a0b6d67-121a-4ac8-a74b-737d52d8b7ac@kernel.org> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Fri, Apr 17, 2026 at 11:57:54AM +0200, David Hildenbrand (Arm) wrote: >On 4/10/26 10:19, Lance Yang wrote: [...] >>> >>> #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? Probably sufficient for the current callers, yes, since they are all THP-related :) But then the helper may return false simply because THP is not built, rather than because the CPU lacks PMD leaf support, which does not match its semantics very well. To be clear, I like static keys too, as I suggested earlier ;) Another boot-time init step that depends on specific init ordering seems a bit shaky to me... At the very least, we'd need to document that ordering very clearly. Cheers, Lance