Re: [PATCH 2/2] kpageflags: fix wrong KPF_THP on non-pmd-mappable compound pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26.06.24 04:49, ran xiaokai wrote:
From: Ran Xiaokai <ran.xiaokai@xxxxxxxxxx>

KPF_COMPOUND_HEAD and KPF_COMPOUND_TAIL are set on "common" compound
pages, which means of any order, but KPF_THP should only be set
when the folio is a 2M pmd mappable THP. Since commit 19eaf44954df

"should only be set" -- who says that? :)

The documentation only talks about "Contiguous pages which construct transparent hugepages". Sure, when it was added there were only PMD ones.


("mm: thp: support allocation of anonymous multi-size THP"),
multiple orders of folios can be allocated and mapped to userspace,
so the folio_test_large() check is not sufficient here,
replace it with folio_test_pmd_mappable() to fix this.


A couple of points:

1) If I am not daydreaming, ever since we supported non-PMD THP in the
   pagecache (much longer than anon mTHP), we already indicate KPF_THP
   for them here. So this is not anon specific? Or am I getting the
   PG_lru check all wrong?

2) Anon THP are disabled as default. If some custom tool cannot deal
   with that "extension" we did with smaller THP, it shall be updated if
   it really has to special-case PMD-mapped THP, before enabled by the
   admin.


I think this interface does exactly what we want, as it is right now. Unless there is *good* reason, we should keep it like that.

So I suggest

a) Extend the documentation to just state "THP of any size and any mapping granularity" or sth like that.

b) Maybe using folio_test_large_rmappable() instead of "(k & (1 <<
   PG_lru)) || is_anon", so even isolated-from-LRU THPs are indicated
   properly.

c) Whoever is interested in getting the folio size, use this flag along
   with a scan for the KPF_COMPOUND_HEAD.


I'll note that, scanning documentation, PAGE_IS_HUGE currently only applies to PMD *mapped* THP. It doesn't consider PTE-mapped THP at all (including PMD-ones). Likely, documentation should be updated to state "PMD-mapped THP or any hugetlb page".

Also kpageflags is not only for userspace memory but for all valid pfn
pages,including slab pages or drivers used pages, so the PG_lru and
is_anon check are unnecessary here.

I'm completely confused about that statements. We do have KPF_OFFLINE, KPF_PGTABLE, KPF_SLAB, ... I'm missing something important.


Signed-off-by: Ran Xiaokai <ran.xiaokai@xxxxxxxxxx>
---
  fs/proc/page.c | 14 ++++----------
  1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/fs/proc/page.c b/fs/proc/page.c
index 2fb64bdb64eb..3e7b70449c2f 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -146,19 +146,13 @@ u64 stable_page_flags(const struct page *page)
  		u |= kpf_copy_bit(k, KPF_COMPOUND_HEAD, PG_head);
  	else
  		u |= 1 << KPF_COMPOUND_TAIL;
+
  	if (folio_test_hugetlb(folio))
  		u |= 1 << KPF_HUGE;
-	/*
-	 * We need to check PageLRU/PageAnon
-	 * to make sure a given page is a thp, not a non-huge compound page.
-	 */
-	else if (folio_test_large(folio)) {
-		if ((k & (1 << PG_lru)) || is_anon)
-			u |= 1 << KPF_THP;
-		else if (is_huge_zero_folio(folio)) {
+	else if (folio_test_pmd_mappable(folio)) {

folio_test_pmd_mappable() would not be future safe. It includes anything >= PMD_ORDER as well.


--
Cheers,

David / dhildenb





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux