Re: [PATCH mm-unstable v1] mm: add a total mapcount for large folios

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09.08.23 23:23, Peter Xu wrote:
Hi, David,

Some pure questions below..
Hi Peter,

thanks for having a look!

[...]

With sub-PMD THP becoming more important and things looking promising
that we will soon get support for such anon THP, we want to avoid looping
over all pages of a folio just to calculate the total mapcount. Further,
we may soon want to use the total mapcount in other context more
frequently, so prepare for reading it efficiently and atomically.
Any (perhaps existing) discussion on reduced loops vs added atomic
field/ops?
So far it's not been raised as a concern, so no existing discussion.

For order-0 pages the behavior is unchanged.

For PMD-mapped THP and hugetlb it's most certainly noise compared to the other activities when (un)mapping these large pages.
For PTE-mapped THP, it might be a bit bigger noise, although I doubt it 
is really significant (judging from my experience on managing 
PageAnonExclusive using set_bit/test_bit/clear_bit when (un)mapping anon 
pages).
As folio_add_file_rmap_range() indicates, for PTE-mapped THPs we should 
be batching where possible (and Ryan is working on some more rmap 
batching). There, managing the subpage mapcount dominates all other 
overhead significantly.
I had a feeling that there's some discussion behind the proposal of this
patch, if that's the case it'll be great to attach the link in the commit
log.
There were (mostly offline) discussions on how to sort out some other 
issues that PTE-mapped THP are facing, and how to eventually get rid of 
the subpage mapcounts (once consumer being _nr_pages_mapped as spelled 
out in the patch description). Having a proper total mapcount available 
was discussed as one building block.
I don't think I have anything of value to link that would make sense for 
the patch as is, as this patch is mostly independent from all that.
--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux