On 4/10/2024 3:22 AM, David Hildenbrand wrote:
Let's track the mapcount of large folios in a single value. The mapcount of
a large folio currently corresponds to the sum of the entire mapcount and
all page mapcounts.
This sum is what we actually want to know in folio_mapcount() and it is
also
On Thu, Apr 18, 2024 at 11:09 PM David Hildenbrand wrote:
>
> On 18.04.24 16:50, Lance Yang wrote:
> > Hey David,
> >
> > FWIW, just a nit below.
>
> Hi!
>
Thanks for clarifying!
> Thanks, but that was done on purpose.
>
> This way, we'll have a memory barrier (due to at least one
> atomic_inc_a
On 18.04.24 16:50, Lance Yang wrote:
Hey David,
FWIW, just a nit below.
Hi!
Thanks, but that was done on purpose.
This way, we'll have a memory barrier (due to at least one
atomic_inc_and_test()) between incrementing the folio refcount
(happening before the rmap change) and incrementing th
Hey David,
FWIW, just a nit below.
diff --git a/mm/rmap.c b/mm/rmap.c
index 2608c40dffad..08bb6834cf72 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1143,7 +1143,6 @@ static __always_inline unsigned int
__folio_add_rmap(struct folio *folio,
int *nr_pmdmapped)
{
atomic_t *ma
On 09.04.24 22:13, Zi Yan wrote:
On 9 Apr 2024, at 15:22, David Hildenbrand wrote:
Let's track the mapcount of large folios in a single value. The mapcount of
a large folio currently corresponds to the sum of the entire mapcount and
all page mapcounts.
This sum is what we actually want to know
On 9 Apr 2024, at 15:22, David Hildenbrand wrote:
> Let's track the mapcount of large folios in a single value. The mapcount of
> a large folio currently corresponds to the sum of the entire mapcount and
> all page mapcounts.
>
> This sum is what we actually want to know in folio_mapcount() and it
