On 13.10.23 02:54, Naoya Horiguchi wrote:
On Thu, Oct 12, 2023 at 05:30:34PM +0200, David Hildenbrand wrote:
On 12.10.23 17:02, Naoya Horiguchi wrote:
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.
Me neither. But in any case a THP *is* a folio. So you'd have to set that
flag in any case.
OK.
And any order-0 page (i.e., anon, pagecache) is also a folio. What you seem
to imply with folio is "large folio". So KPF_FOLIO is really wrong as far as
I can tell.
Ah, I meant "large folio" for the new flag, so it might have been better to
name it KPF_LARGE_FOLIO.
"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.
I keep forgetting if "folio" is just the generic term for any order-0 or
compound page, or only for some of them. I usually live in the "anon" world,
so I don't get reminded that often :)
I didn't notice that an order-0 page is also a 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.
We are currently considering calling these sub-PMD sized THPs "small-sized
THP". [1] Arguably, we're starting with the anon part where we won't get
around exposing them to the user in sysfs.
So I wouldn't immediately say that these things are not THPs. They are not
PMD-sized THP. A slab/hugetlb is certainly not a thp but a folio. Whereby
slabs can also be order-0 folios, but hugetlb can't.
Looking at other interfaces, we do expose:
include/uapi/linux/kernel-page-flags.h:#define KPF_COMPOUND_HEAD 15
include/uapi/linux/kernel-page-flags.h:#define KPF_COMPOUND_TAIL 16
So maybe we should just continue talking about compound pages or do we have
to use both terms here in this interface?
Extending the concept of thp to arbitrary size of thp sounds good to me.
If patchset [1] will be merged, then setting KPF_THP on large folios is totally
fine and one of my problem in this patchset will be automatically resolved.
CCing Ryan.
So I'm thinking of not adding new flag and just focusing on garbage data issue.
That sounds minimal and reasonable! Flags/values that logically belong
to the head (although are stored in the tail) should probably be exposed
along with the head. Flags that apply to the actual tail pages should
stay with the tail pages.
Thank you very much for sharing ideas.
Thank you!
--
Cheers,
David / dhildenb