On 27/03/2024 15:13, Ryan Roberts wrote:
> On 27/03/2024 14:57, David Hildenbrand wrote:
>> On 27.03.24 15:53, Matthew Wilcox wrote:
>>> On Sat, Mar 23, 2024 at 12:41:36AM +1300, Barry Song wrote:
>>>> Commit d0637c505f8a1 ("arm64: enable THP_SWAP for arm64") brings up
>>>> THP_SWAP on ARM64, but it doesn't enable THP_SWP on hardware with
>>>> MTE as the MTE code works with the assumption tags save/restore is
>>>> always handling a folio with only one page.
>>>>
>>>> The limitation should be removed as more and more ARM64 SoCs have
>>>> this feature. Co-existence of MTE and THP_SWAP becomes more and
>>>> more important.
>>>>
>>>> This patch makes MTE tags saving support large folios, then we don't
>>>> need to split large folios into base pages for swapping out on ARM64
>>>> SoCs with MTE any more.
>>>
>>> Can we go further than this patch and only support PG_mte_tagged and
>>> PG_mte_lock on folio->flags instead of page->flags? We're down to using
Also, I wouldn't want to hold this patch up in order to do this extra work. I
think the 2 things are orthogonal? (supporting THP swap with MTE vs not using
tail page flags for MTE). Can we discuss and handle it separately?
>>
>> I think we discussed that already and what I learned is that it "gets a bit
>> complicated". But I'm hoping we can get that discussion started again.
>
> The original conversation starts here:
> https://lore.kernel.org/linux-mm/fb34d312-1049-4932-8f2b-d7f33cfc297c@xxxxxxx/
>
> The issue is that you can have a large folio mapped to user space, and user
> space only wants to activate MTE for a portion of it. So at that point, you
> either have to deal with only part of it being tagged (as we do today with the
> per-page flag) or you have to split the folio.
>
> I haven't re-read the entire thread - so might be forgetting some important details.
>
>>
>>> page->flags for these two MTE bits, a whole lot of s390 junk, PG_hwpoison,
>>> PG_head, PG_anon_exclusive and Zone/Section/Node/KASAN/last_cpupid.
>>
>> ... just like PG_anon_exclusive "gets a bit complicated". Well, I think I might
>> have finally found a way to make it work, I'll only have to uglify fork() a bit.
>>
>
