On Wed, Apr 24, 2024 at 09:00:50PM -0700, John Hubbard wrote: > > We want to limit the use of page_mapcount() to places where absolutely > > required, to prepare for kernel configs where we won't keep track of > > per-page mapcounts in large folios. > > > Just curious, can you elaborate on the motivation? I probably missed > the discussions that explained why page_mapcount() in large folios > is not desirable. Are we getting rid of a field in struct page/folio? > Some other reason? Two reasons. One is that, regardless of anything else, folio_mapcount() is expensive on large folios as it has to walk every page in the folio summing the mapcounts. The more important reason is that when we move to separately allocated folios, we don't want to allocate an array of mapcounts in order to maintain a per-page mapcount. So we're looking for a more compact scheme to avoid maintaining a per-page mapcount. > > The khugepage MM selftests keep working as expected, including: > > > > Run test: collapse_max_ptes_shared (khugepaged:anon) > > Allocate huge page... OK > > Share huge page over fork()... OK > > Trigger CoW on page 255 of 512... OK > > Maybe collapse with max_ptes_shared exceeded.... OK > > Trigger CoW on page 256 of 512... OK > > Collapse with max_ptes_shared PTEs shared.... OK > > Check if parent still has huge page... OK > > Well, a word of caution! These tests do not (yet) cover either of > the interesting new cases that folio_likely_mapped_shared() presents: > KSM or hugetlbfs interactions. In other words, false positives. Hmm ... KSM never uses large folios and hugetlbfs is disjoint from khugepaged?
