Re: [PATCH 7/9] mm: Add deferred_list page flag

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


On 15.08.23 21:58, Matthew Wilcox wrote:
On Tue, Aug 15, 2023 at 07:27:26PM +0200, David Hildenbrand wrote:
On 15.08.23 19:06, Matthew Wilcox wrote:
Theree are a lot of counters called THP and TransHuge and other variants
which are exposed to userspace, and the (user) assumption is that this counts
PMD-sized folios.  If you grep around for folio_test_pmd_mappable(),
you'll find them.  If we have folio_test_thp(), people will write:

	if (folio_test_thp(folio))
		__mod_lruvec_state(lruvec, NR_SHMEM_THPS, nr);

instead of using folio_test_pmd_mappable().

So if we *really* don't want to use THP to express that we have a page, then
let's see what these pages are:
* can be mapped to user space
* are transparent to most MM-related systemcalls by (un) mapping
   them in system page size (PTEs)

  * Are managed on the LRU
  * Can be dirtied, written back

Right, but at least hugetlb *could* be extended to do that as well (and even implement swapping). I think the biggest difference is the transparency/PTE-mapping/unmapping/ ....

That we can split these pages (not PTE-map, but convert from large folio to
small folios) is one characteristic, but IMHO not the main one (and maybe
not even required at all!).

It's the one which distinguishes them from, say, compound pages used for
slab.  Or used by device drivers.  Or net pagepool, or vmalloc.  There's
a lot of compound allocations out there, and the only ones which need
special treatment here are the ones which are splittable.

And my point is that that is an implementation detail I'm afraid. Instead of splitting the folio into order-0 folios, you could also migrate off all data to order-0 folios and just free the large folio.

Because splitting only succeeds if there are no other references on the folio, just like migration.

But let's not get distracted :)

Maybe we can come up with a better term for "THP, but not necessarily

"Large folio" is IMHO bad. A hugetlb page is a large folio and not all large
folios can be mapped to user space.

"Transparent large folios" ? Better IMHO.

I think this goes back to Johannes' point many months ago that we need
separate names for some things.  He wants to split anon & file memory
apart (who gets to keep the name "folio" in the divorce?  what do we
name the type that encompasses both folios and the other one?  or do
they both get different names?)

Good question. I remember discussing a type hierarchy back when you upstreamed folios.

Maybe we would have "file folios" and "anon folios.

Perhaps the key difference between normal compound pages and file/anon
compound pages is that the latter are splittable?  So we can name all
of this:


Maybe that's still too close to an implementation detail, but it's at
least talking about _a_ characteristic of the folio, even if it's not
the _only_ characteristic of the folio.

Maybe folio_init_transparent() ... avoiding the "huge" part of it.

Very open for alternatives. As expressed in other context, we really should
figure this out soon.

Yeah, I'm open to better naming too.  At this point in the flow we're
trying to distinguish between compound pages used for slab and compound
pages used for anon/file, but that's not always going to be the case

Yes. Let me reply to your other mail.


David / dhildenb

[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux