From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) (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 013A210F1 for ; Sun, 17 May 2026 12:42:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779021748; cv=none; b=GMPWytcnN3H70Ad8ViSN1YyqUnruG004OlQQ3NgGUnwd0qog9L9mBYg2/UndibBHW0Sk0BcNJ1/tnEQUBaEPI28hkq6c1dAlKM1xUyDb+2duoqGFEwKBBDQ2K3xQ2y/djc44/taA7k/C+5PYcZ+YaBW2YCKEdQgnMX8+V7Z3fqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779021748; c=relaxed/simple; bh=IOFiyCRRoG3t7BN5wIgC+SLf0ZQBe2VtEpYmNJ9ieTM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=SKHPGKrbbLbVhXkT2WU+jTqIszIEM2CR9yIwMOcbwNWgr+GCFaMxjLt0UUWFiYPEYLCVFmnIR0oqsyLBdkFSI27wmcwWNyZPj/A3Ersq5WBMrOVSaHMKHvcC4EovYQ4mfS6nmFtTd8Z4EZJaA3eRwbb+/4SGNBD9zgYjYt1iJpo= 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=Q6m8bZx/; arc=none smtp.client-ip=95.215.58.178 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="Q6m8bZx/" 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=1779021744; 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=BncCr1BHhklgYgkp0UUalpttn/IeZ5vtGECGgen9ulE=; b=Q6m8bZx/XTLt3n5y/1PdEf1Rb6GWUwbzj3M9g0nhVgZHHlHwlpCWFiz7GX+KdTF/TN7DVl yHsGa6rl40uKnIsO5h6PqFbdpoC8tlGcHy702XAJCkE7g+knlE3cUZwAZp9k/liQm739fh 15BJdEMkvARdskMzkt4pRhcSv52l76s= 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:41:49 +0800 Message-Id: <20260517124149.90033-1-lance.yang@linux.dev> In-Reply-To: <1f4bccaf-6472-4e4c-92d0-28ac05f6f838@redhat.com> References: <1f4bccaf-6472-4e4c-92d0-28ac05f6f838@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 10:18:48PM -0400, Luiz Capitulino wrote: >On 2026-05-13 11:36, 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. >> >> Oh, one more thing: what will be the semantics regarding >> CONFIG_TRANSPARENT_HUGEPAGE? >> >> I assume it will only return true if CONFIG_TRANSPARENT_HUGEPAGE is enabled, >> correct? >> >> That is, for example, relevant for patch #2. >> >> We could later change these semantics, but for now we should be very clear about >> what it means. > >I intended to decouple the API from CONFIG_TRANSPARENT_HUGEPAGE,so my >goal was to return true as long as PMD-sized pages are supported[*]. If >arch_has_pmd_leaves() is not implemented by the arch, we default to >CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE, not CONFIG_TRANSPARENT_HUGEPAGE. After patch #07, what still confuses me a bit is that the arch hoooks for arch_has_pmd_leaves() still seems to be guarded by CONFIG_TRANSPARENT_HUGEPAGE, not CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE .. For example, x86 only define arch_has_pmd_leaves() when CONFIG_TRANSPARENT_HUGEPAGE=y, Same for s390 and mips, unless I missed something. So is the intended meaning: "this arch can support PMD leaves" or "this CPU actually supports PMD leaves" ? If it's the second one, shouldn't the arch_has_pmd_leaves hooks move out of the CONFIG_TRANSPARENT_HUGEPAGE guards as well? >Now, do you mean to say that the API should still be tied to >CONFIG_TRANSPARENT_HUGEPAGE? If yes, why? > > * Sashiko found out that the current arch_has_pmd_leaves() > implementation for x86 (and possibly the other archs) is guarded by > CONFIG_TRANSPARENT_HUGEPAGE, so we may return true without the > hardware check. But that's a bug Not sure whether that bug can actually happen ... But decoupling them looks cleaner to me :) CONFIG_TRANSPARENT_HUGEPAGE controls whether THP code is built, while arch_has_pmd_leaves() is about PMD-leaf capability. Cheers, Lance