From: Svetly Todorov <svetly.todorov@memverge.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, gregory.price@memverge.com,
willy@infradead.org, wangkefeng.wang@huawei.com,
akpm@linux-foundation.org, david@redhat.com, vbabka@suse.cz,
naoya.horiguchi@linux.dev,
Svetly Todorov <svetly.todorov@memverge.com>
Subject: [PATCH v3] kpageflags: respect folio head-page flag placement
Date: Wed, 20 Mar 2024 10:28:09 -0700 [thread overview]
Message-ID: <20240320-kpageflags-svetly-v3-1-b6725843bfa7@memverge.com> (raw)
---
Page flags are now stored per-folio. Change kpageflags to report these
per-folio flags where appropriate.
Most folio flags are set on the head page, i.e. *folio_flag(page, 0).
Only three are set on the second page -- PG_has_hwpoisoned, PG_large_rmappable,
and PG_hugetlb. kpageflags doesn't report the first two, and the PG_hugetlb
check is handled by calls to PageHuge/PageTransCompound(), so no code changes
are required for these flags.
mm/memory-failure.c applies PG_HWPoison via SetPageHWPoison(page).
This call falls through to the SetPage##uname macro in
include/linux/page-flags.h, which sets the corresponding PG_##lname bit
on the given page struct. Therefore KPF_HWPOISON must come from page->flags.
arch/xtensa/mm/cache.c tests and sets the PG_arch1 bit in both
folio->flags and page->flags. So both sources are OR'd into KPF_ARCH.
As for arch2 and arch3, Kefeng Wang reported that they appear only as
arm64-specific aliases: namely, PG_mte_tagged and PG_mte_lock.
Both are applied to page->flags via set_bit() in arch/arm64/include/asm/mte.h.
So those must come from page->flags, too.
Signed-off-by: Svetly Todorov <svetly.todorov@memverge.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Suggested-by: Gregory Price <gregory.price@memverge.com>
Suggested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Link: https://lore.kernel.org/all/20231030180005.2046-1-gregory.price@memverge.com/
Link: https://80x24.org/lore/linux-mm/20231110033324.2455523-4-wangkefeng.wang@huawei.com/
Link: https://80x24.org/lore/linux-mm/438ba640-c205-4034-886e-6a7231f3d210@huawei.com/
---
fs/proc/page.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 195b077c0fac..290470819fa2 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -110,6 +110,7 @@ static inline u64 kpf_copy_bit(u64 kflags, int ubit, int kbit)
u64 stable_page_flags(struct page *page)
{
u64 k;
+ u64 p;
u64 u;
/*
@@ -119,7 +120,8 @@ u64 stable_page_flags(struct page *page)
if (!page)
return 1 << KPF_NOPAGE;
- k = page->flags;
+ k = *folio_flags(page, 0);
+ p = page->flags;
u = 0;
/*
@@ -205,7 +207,7 @@ u64 stable_page_flags(struct page *page)
u |= kpf_copy_bit(k, KPF_MLOCKED, PG_mlocked);
#ifdef CONFIG_MEMORY_FAILURE
- u |= kpf_copy_bit(k, KPF_HWPOISON, PG_hwpoison);
+ u |= kpf_copy_bit(p, KPF_HWPOISON, PG_hwpoison);
#endif
#ifdef CONFIG_ARCH_USES_PG_UNCACHED
@@ -216,11 +218,14 @@ u64 stable_page_flags(struct page *page)
u |= kpf_copy_bit(k, KPF_MAPPEDTODISK, PG_mappedtodisk);
u |= kpf_copy_bit(k, KPF_PRIVATE, PG_private);
u |= kpf_copy_bit(k, KPF_PRIVATE_2, PG_private_2);
+ u |= kpf_copy_bit(p, KPF_PRIVATE, PG_private);
+ u |= kpf_copy_bit(p, KPF_PRIVATE_2, PG_private_2);
u |= kpf_copy_bit(k, KPF_OWNER_PRIVATE, PG_owner_priv_1);
u |= kpf_copy_bit(k, KPF_ARCH, PG_arch_1);
+ u |= kpf_copy_bit(p, KPF_ARCH, PG_arch_1);
#ifdef CONFIG_ARCH_USES_PG_ARCH_X
- u |= kpf_copy_bit(k, KPF_ARCH_2, PG_arch_2);
- u |= kpf_copy_bit(k, KPF_ARCH_3, PG_arch_3);
+ u |= kpf_copy_bit(p, KPF_ARCH_2, PG_arch_2);
+ u |= kpf_copy_bit(p, KPF_ARCH_3, PG_arch_3);
#endif
return u;
---
base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
change-id: 20240319-kpageflags-svetly-9faa11b17022
Best regards,
--
Svetly Todorov <svetly.todorov@memverge.com>
next reply other threads:[~2024-03-20 17:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 17:28 Svetly Todorov [this message]
2024-03-20 19:24 ` Matthew Wilcox
2024-03-20 23:40 ` Svetly Todorov
2024-03-21 16:03 ` Matthew Wilcox
2024-03-21 19:08 ` Svetly Todorov
2024-03-21 19:59 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240320-kpageflags-svetly-v3-1-b6725843bfa7@memverge.com \
--to=svetly.todorov@memverge.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gregory.price@memverge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naoya.horiguchi@linux.dev \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox