On 02.07.23 14:26, Matthew Wilcox wrote:
On Sun, Jul 02, 2023 at 01:45:48PM +0200, David Hildenbrand wrote:
Further, for (1) we'd want a 64bit mapcount for large folios, which implies
a 64bit refcount. For smallish folios, we don't really care.
We should most probably use a bi-weekly MM meeting to discuss that.
We have a bi-weekly meeting to discuss all these things; it's the same
time/day as the MM meeting, but the other weeks in-between.
Is there some kind of official invitation with meeting details that I
missed?
In any case, I'd appreciate a pointer, so I can join.
Last one, we discussed the idea of having a 64-bit mapcount stored in
a tail page, but having mapcount only contribute 1 to refcount instead
of refcount being incremented for every mapcount. We do this trick with
mm_users and mm_count (for different reasons, but it's not
unprecedented).
Okay, to avoid a 64bit refcount for higher-order folios.
eg we could do this as:
page_add_anon_rmap:
if (folio_test_large(folio))
first = atomic64_inc_and_test(&folio->_mapcount64)
else
first = atomic_inc_and_test(&page->_mapcount);
if (!first)
folio_put(folio);
which is substantially simpler than what's there now. The accounting
needs a bit of extra work.
Some places that check for page_count() == 1 have to be taught about
that as well.
Also, the rmap vs. refcount handling for __tlb_remove_page() e.g., in
zap_pte_range() has to be considered: just because we dropped the
mapcount doesn't mean we want to drop the refcount. Maye we could take
an extra ref for that.
It surely doesn't sound completely crazy, but this needs more thought
(and you discussed that in the meeting most probably already).
--
Cheers,
David / dhildenb
