linux-kernel - Re: [PATCH v4 4/6] mm: Introduce a pageflag for partially mapped folios

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]

Message-ID: <5ed479c9-21eb-4bc8-8c17-79e1b6081355@gmail.com>
Date: Wed, 21 Aug 2024 15:04:20 -0400
From: Usama Arif <usamaarif642@...il.com>
To: Barry Song <baohua@...nel.org>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org, hannes@...xchg.org,
 riel@...riel.com, shakeel.butt@...ux.dev, roman.gushchin@...ux.dev,
 yuzhao@...gle.com, david@...hat.com, ryan.roberts@....com, rppt@...nel.org,
 willy@...radead.org, cerasuolodomenico@...il.com, ryncsn@...il.com,
 corbet@....net, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 kernel-team@...a.com
Subject: Re: [PATCH v4 4/6] mm: Introduce a pageflag for partially mapped
 folios

On 20/08/2024 17:30, Barry Song wrote:

> Hi Usama,
> thanks! I can't judge if we need this partially_mapped flag. but if we
> need, the code
> looks correct to me. I'd like to leave this to David and other experts to ack.
> 

Thanks for the reviews!

> an alternative approach might be two lists? one for entirely_mapped,
> the other one
> for split_deferred. also seems ugly ?
> 

That was my very first prototype! I shifted to using a bool which I sent in v1, and then a bit in _flags_1 as David suggested. I believe a bit in _flags_1 is the best way forward, as it leaves the most space in folio for future work.

> On the other hand, when we want to extend your patchset to mTHP other than PMD-
> order, will the only deferred_list create huge lock contention while
> adding or removing
> folios from it?
> 

Yes, I would imagine so. the deferred_split_queue is per memcg/node, so that helps.

Also, this work is tied to khugepaged. So would need some thought when doing it for mTHP.

I would imagine doing underused shrinker for mTHP would be less beneficial compared to doing it for 2M THP. But probably needs experimentation.

Thanks