linux-kernel - Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 20 Apr 2024 18:31:58 +0200
From: David Hildenbrand <david@...hat.com>
To: Lance Yang <ioworker0@...il.com>, Matthew Wilcox <willy@...radead.org>
Cc: akpm@...ux-foundation.org, maskray@...gle.com, ziy@...dia.com,
 ryan.roberts@....com, 21cnbao@...il.com, mhocko@...e.com,
 fengwei.yin@...el.com, zokeefe@...gle.com, shy828301@...il.com,
 xiehuan09@...il.com, wangkefeng.wang@...wei.com, songmuchun@...edance.com,
 peterx@...hat.com, minchan@...nel.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during
 shrink_folio_list()

On 20.04.24 17:04, Lance Yang wrote:
> On Sat, Apr 20, 2024 at 12:59 PM Lance Yang <ioworker0@...il.com> wrote:
>>
>> Hey Matthew,
>>
>> Thanks for taking time to review!
>>
>> On Wed, Apr 17, 2024 at 11:09 PM Matthew Wilcox <willy@...radead.org> wrote:
>>>
>>> On Wed, Apr 17, 2024 at 10:11:11PM +0800, Lance Yang wrote:
>>>> When the user no longer requires the pages, they would use madvise(madv_free)
>>>> to mark the pages as lazy free. IMO, they would not typically rewrite to the
>>>> given range.
>>>>
>>>> At present, a PMD-mapped THP marked as lazyfree during shrink_folio_list()
>>>> is unconditionally split, which may be unnecessary. If the THP is exclusively
>>>> mapped and clean, and the PMD associated with it is also clean, then we can
>>>> attempt to remove the PMD mapping from it. This change will improve the
>>>> efficiency of memory reclamation in this case.
>>>>
>>>> On an Intel i5 CPU, reclaiming 1GiB of PMD-mapped THPs using
>>>> mem_cgroup_force_empty() results in the following runtimes in seconds
>>>> (shorter is better):
>>>>
>>>> --------------------------------------------
>>>> |     Old       |      New       |  Change  |
>>>> --------------------------------------------
>>>> |   0.683426    |    0.049197    |  -92.80% |
>>>> --------------------------------------------
>>>>
>>>> Signed-off-by: Lance Yang <ioworker0@...il.com>
>>>> ---
>>>>   include/linux/huge_mm.h |  1 +
>>>>   include/linux/rmap.h    |  1 +
>>>>   mm/huge_memory.c        |  2 +-
>>>>   mm/rmap.c               | 81 +++++++++++++++++++++++++++++++++++++++++
>>>>   mm/vmscan.c             |  7 ++++
>>>>   5 files changed, 91 insertions(+), 1 deletion(-)
>>>
>>> I'm confused why we need all this extra code.  If we remove a folio
>>
>> Thanks for pointing that out!
>>
>> I've added a lot of extra code to rmap.c, and we don't need it
>> for file pages - sorry. I'll reconsider where to place this code.
>>
>>> from the pagecache, we can just call truncate_inode_folio() and
>>> unmap_mapping_folio() takes care of all the necessary unmappings.
>>> Why can't you call unmap_mapping_folio() here?
>>
>> Thanks for your suggestion.
>>
>> But this change only avoids the splitting of *anon* large folios
>> (PMD-mapped THPs) that are marked as lazyfree during
>> shrink_folio_list().
>>
>> IIUC, in some cases, we cannot unmap the THP marked as lazyfree
>> here, such as when it's not exclusively mapped, dirty, pinned, etc.
> 
> I’d like to make a correction.
> 
> IMO, we can unmap the THP that is not exclusively mapped, but
> ensuring folio_ref_count() equals folio_mapcount() +1.

You must follow the exact same logic as in try_to_unmap_one() I guess.

That is, unmap the page, syncing against concurrent GUP-fast. Then, 
check mapcount vs. refcount. If there are unexpected references, remap 
the page (set_pte_at).

-- 
Cheers,

David / dhildenb