[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5e29217-11d3-a84b-9e29-44acc72222f3@redhat.com>
Date: Thu, 10 Aug 2023 10:59:47 +0200
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-doc@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>,
Mike Kravetz <mike.kravetz@...cle.com>,
Hugh Dickins <hughd@...gle.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Ryan Roberts <ryan.roberts@....com>,
Yin Fengwei <fengwei.yin@...el.com>,
Yang Shi <shy828301@...il.com>, Zi Yan <ziy@...dia.com>
Subject: Re: [PATCH mm-unstable v1] mm: add a total mapcount for large folios
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
Powered by blists - more mailing lists