From: Naoya Horiguchi <naoya.horiguchi@linux.dev>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Vlastimil Babka <vbabka@suse.cz>,
Muchun Song <songmuchun@bytedance.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/5] mm, kpageflags: support folio and fix output for compound pages
Date: Fri, 13 Oct 2023 00:02:26 +0900 [thread overview]
Message-ID: <20231012150226.GA473412@u2004> (raw)
In-Reply-To: <63d119f7-5adb-861a-00c2-69a92b19ef9b@redhat.com>
On Thu, Oct 12, 2023 at 10:33:04AM +0200, David Hildenbrand wrote:
> On 10.10.23 16:27, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > This patchset addresses 2 issues in /proc/kpageflags.
> >
> > 1. We can't easily tell folio from thp, because currently both pages are
> > judged as thp, and
> > 2. we see some garbage data in records of compound tail pages because
> > we use tail pages to store some internal data.
> >
> > These issues require userspace programs to do additional work to understand
> > the page status, which makes situation more complicated.
> >
> > This patchset tries to solve these by defining KPF_FOLIO for issue 1., and
> > by hiding part of page flag info on tail pages of compound pages for issue 2.
> >
> > I think that technically some compound pages like thp/hugetlb/slab could be
> > considered as folio, but in this version KPF_FOLIO is set only on folios
>
> At least thp+hugetlb are most certainly folios. Regarding slab, I suspect we
> no longer call them folios (cannot be mapped to user space). But Im not sure
> about the type hierarchy.
I'm not sure about the exact definition of "folio", and I think it's better
to make KPF_FOLIO set based on the definition.
"being mapped to userspace" can be one possible criteria for the definition.
But reading source code, folio_slab() and slab_folio() convert between
struct slab and struct folio, so I feel that someone might think a slab is
a kind of folio.
>
> > in pagecache (so "folios in narrower meaning"). I'm not confident about
> > this choice, so if you have any idea about this, please let me know.
>
> It does sound inconsistent. What exactly do you want to tell user space with
> the new flag?
The current most problematic behavior is to report folio as thp (order-2
pagecache page is definitely a folio but not a thp), and this is what the
new flag is intended to tell.
Thanks,
Naoya Horiguchi
next prev parent reply other threads:[~2023-10-12 15:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 14:27 [PATCH v1 0/5] mm, kpageflags: support folio and fix output for compound pages Naoya Horiguchi
2023-10-10 14:27 ` [PATCH v1 1/5] include/uapi/linux/kernel-page-flags.h: define KPF_FOLIO Naoya Horiguchi
2023-10-10 14:27 ` [PATCH v1 2/5] mm: kpageflags: distinguish thp and folio Naoya Horiguchi
2023-10-10 14:27 ` [PATCH v1 3/5] mm, kpageflags: separate code path for hugetlb pages Naoya Horiguchi
2023-10-10 14:28 ` [PATCH v1 4/5] mm, kpageflags: fix invalid output for PageSlab Naoya Horiguchi
2023-10-10 14:28 ` [PATCH v1 5/5] tools/mm/page-types.c: hide compound pages in non-raw mode Naoya Horiguchi
2023-10-12 8:33 ` [PATCH v1 0/5] mm, kpageflags: support folio and fix output for compound pages David Hildenbrand
2023-10-12 15:02 ` Naoya Horiguchi [this message]
2023-10-12 15:30 ` David Hildenbrand
2023-10-13 0:54 ` Naoya Horiguchi
2023-10-13 7:46 ` David Hildenbrand
2023-10-13 15:03 ` Matthew Wilcox
2023-10-16 10:13 ` David Hildenbrand
2023-10-16 11:36 ` Ryan Roberts
2023-10-18 5:25 ` Naoya Horiguchi
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=20231012150226.GA473412@u2004 \
--to=naoya.horiguchi@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=naoya.horiguchi@nec.com \
--cc=songmuchun@bytedance.com \
--cc=vbabka@suse.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.