From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 A37DC405C5F for ; Sun, 17 May 2026 12:03:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779019432; cv=none; b=qoTmVoqa1IG4LsS9sBSmeuk9dRRncMAApp3ooemxjSh6M+RhrEpAxuio3JeQpkQ7HXHpr8mOVa26343AcsLfmNHnV6iPL9gVAz/Iln/y44P+54adagasRhGO8/blX9/5lq43UlFKVxYK0kVJQ0u+w2oTJioonN4gSahQWy5BCHw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779019432; c=relaxed/simple; bh=Kvh65hn2EA50RNNYwU/b8kvNDjlCNeo/IZPh/nBUxg4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=UvdhsZPiGVgqf5tOklyKeQXDUumpB0pUIjOwLQaYN6UR3YF1Av11mrGkVpP6ukO1TdITdNcyWRtx37rrdEPan0QB62WRaIK9WtaqYwJEn26/iVBvK/86M0Ou0EOamr006ymdkEEJeDahaWpVsfcOtWn65iJs0tmzdCoV/bG0lBs= 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=XayuKuYk; arc=none smtp.client-ip=91.218.175.172 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="XayuKuYk" 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=1779019427; 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=uzAHTZq9a1jN0cBlc3SNJJ0CnrHRNLBC13c5Nsix0sU=; b=XayuKuYkB18z5SlEgwurM6lOcrv/JPfJnlh1pVfuLc3lc0W7WAnCsugfqZ1qH4rEG3qso7 UP26Cljvrr66pZICIUqzgrrZIxqBMF07YN0Uknwrzdn+S9CsKRLsf/105e+d6+wf6fiyB5 FoTIArGY7IQ0lZwFUPg/51VboDuwLzk= From: Lance Yang To: luizcap@redhat.com, david@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, ziy@nvidia.com, lance.yang@linux.dev, 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 Subject: Re: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves() Date: Sun, 17 May 2026 20:03:28 +0800 Message-Id: <20260517120328.63143-1-lance.yang@linux.dev> In-Reply-To: <8d365dfa-98e0-478b-ba6b-377c939865d4@redhat.com> References: <8d365dfa-98e0-478b-ba6b-377c939865d4@redhat.com> 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 Wed, May 13, 2026 at 09:52:05PM -0400, Luiz Capitulino wrote: [...] >>> >>> #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()? Indeed. If nobody needs pgtable_has_pmd_leaves() that early, it is cleaner to put it in MM init code :) >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. Or what about pgtable_leaf_support_init()? It says what this init is for, setting up the cached leaf-support check. Today that only means PMD leaves, but the name still works if we add PUD leaves later :) Cheers, Lance