[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0b4a134-1d40-4eef-94f3-5c4593b55e78@redhat.com>
Date: Thu, 13 Jun 2024 10:49:01 +0200
From: David Hildenbrand <david@...hat.com>
To: Barry Song <21cnbao@...il.com>, akpm@...ux-foundation.org,
linux-mm@...ck.org
Cc: chrisl@...nel.org, linux-kernel@...r.kernel.org, mhocko@...e.com,
ryan.roberts@....com, baolin.wang@...ux.alibaba.com, yosryahmed@...gle.com,
shy828301@...il.com, surenb@...gle.com, v-songbaohua@...o.com,
willy@...radead.org, ying.huang@...el.com, yuzhao@...gle.com
Subject: Re: [PATCH RFC 3/3] mm: remove folio_test_anon(folio)==false path in
__folio_add_anon_rmap()
On 13.06.24 10:46, Barry Song wrote:
> On Thu, Jun 13, 2024 at 12:08 PM Barry Song <21cnbao@...il.com> wrote:
>>
>> From: Barry Song <v-songbaohua@...o.com>
>>
>> The folio_test_anon(folio)==false case within do_swap_page() has been
>> relocated to folio_add_new_anon_rmap(). Additionally, two other callers
>> consistently pass anonymous folios.
>>
>> stack 1:
>> remove_migration_pmd
>> -> folio_add_anon_rmap_pmd
>> -> __folio_add_anon_rmap
>>
>> stack 2:
>> __split_huge_pmd_locked
>> -> folio_add_anon_rmap_ptes
>> -> __folio_add_anon_rmap
>>
>> __folio_add_anon_rmap() only needs to handle the cases
>> folio_test_anon(folio)==true now.
>
> My team reported a case where swapoff() is calling
> folio_add_anon_rmap_pte *not* folio_add_anon_rmap_ptes
> with one new anon (!folio_test_anon(folio)).
>
> I will double check all folio_add_anon_rmap_pte() cases.
Right, swapoff() path is a bit special (e.g., we don't do any kind of
batching on the swapoff() path).
But we should never get a new large anon folio there, or could that now
happen?
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists