On 02.07.23 11:50, Yin, Fengwei wrote:
On 7/1/2023 9:17 AM, Zi Yan wrote:
In kernel, almost all code only cares: 1) if a page/folio has extra pins
by checking if mapcount is equal to refcount + extra, and 2)
if a page/folio is mapped multiple times. A single mapcount can meet
these two needs.
For 2, how can we know whether a page/folio is mapped multiple times from
single mapcount? My understanding is we need two counts as folio could be
partial mapped.
Yes, a single mapcount is most probably insufficient. I started
analyzing all existing users and use cases, trying to avoid walking page
tables.
If we want to get rid of all of (most) sub-page mapcounts, we'd probably
want:
(1) Total mapcount (compound + any sub-page): page_mapped(), pagecount
vs. refcount games, ...
(2) Compound mapcount (for PMD/PUD-mappale THP only): (2) - (1) tells
you if it's only PMD mapped or also PTE-mapped. For example, for
statistics but also swapout code.
(3) Mapcount of first (or any other) subpage (compount+subpage): for
folio_estimated_sharers().
For anon pages, I'm thinking about remembering an additional
(1) Page/folio creator (MM pointer/identification)
(2) Page/folio creator mapcount
When optimizing a PTE-mapped THP (especially not- pmd-mappale) for the
fork()+exec() case, we'd have to walk page tables to see if all folio
references come from this MM. The page/folio creator exactly avoids that
completely. We might need a mechanism to synchronize against
mapping/unmapping of this folio from the creator concurrently (relevant
when mapped into multiple page tables).
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.
Hopefully, I have a full understanding of all use cases and requirements
until then. Don't have sufficient time to look into all the nasty
details right now.
--
Cheers,
David / dhildenb
