Re: Folio mapcount

[David Hildenbrand <david@redhat.com>]

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