On 15.08.23 19:06, Matthew Wilcox wrote:
On Tue, Aug 15, 2023 at 06:40:55PM +0200, David Hildenbrand wrote:
On 15.08.23 17:32, Matthew Wilcox wrote:
On Tue, Aug 15, 2023 at 09:54:36AM +0200, David Hildenbrand wrote:
On 15.08.23 05:26, Matthew Wilcox (Oracle) wrote:
Stored in the first tail page's flags, this flag replaces the destructor.
That removes the last of the destructors, so remove all references to
folio_dtor and compound_dtor.
Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
---
[...]
+ /* Has a deferred list (may be empty). First tail page. */
+ PG_deferred_list = PG_reclaim,
+
If PG_deferred_list implies thp (and replaces the thp dtor), should we
rather name this PG_thp or something along those lines?
We're trying to use 'thp' to mean 'a folio which is pmd mappable',
so I'd rather not call it that.
There is no conclusion on that.
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)
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!).
Maybe we can come up with a better term for "THP, but not necessarily
PMD-sized".
"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.
After all, the deferred split queue is just an implementation detail, and it
happens to live in tailpage 2, no?
Once we would end up initializing something else in prep_transhuge_page(),
it would turn out pretty confusing if that is called folio_remove_deferred()
...
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:
folio_init_splittable()
folio_test_splittable()
folio_fini_splittable()
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.
--
Cheers,
David / dhildenb
