linux-kernel - Re: [RFC PATCH 0/3] asynchronously scan and free empty user PTE pages

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] [day] [month] [year] [list]

Message-ID: <0317efd5-f7f8-4fd2-8892-befe9fe97f33@bytedance.com>
Date: Tue, 18 Jun 2024 17:55:17 +0800
From: Qi Zheng <zhengqi.arch@...edance.com>
To: David Hildenbrand <david@...hat.com>
Cc: hughd@...gle.com, willy@...radead.org, mgorman@...e.de,
 muchun.song@...ux.dev, akpm@...ux-foundation.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] asynchronously scan and free empty user PTE pages



On 2024/6/18 17:40, David Hildenbrand wrote:
> On 18.06.24 09:51, Qi Zheng wrote:
>> Hi David,
>>
>> On 2024/6/18 01:49, David Hildenbrand wrote:
>>>
>>>>>
>>>>> No strong opinion, something synchronous sounds to me like the
>>>>> low-hanging fruit, that could add the infrastructure to be used by
>>>>> something more advanced/synchronously :)
>>>>
>>>> Got it, I will try to do the following in the next version.
>>>>
>>>> a. for MADV_DONTNEED case, try synchronous reclaim as you said
>>>>
>>>
>>> I think that really is the low hanging fruit that would cover quite some
>>> cases already: (1) reclaim when MADV_DONTNEED spans the complete page
>>> table.
>>
>> I will check and free the PTE page in the zap_pte_range() if the
>> (end - addr >= PMD_SIZE) condition is met.
>>
>>>
>>> Then, there is (2) reclaim when MADV_DONTNEED spans only part of the
>>> page table (e.g., single PTE), but my best guess is that it's better to
>>> scan for that asynchronously than making possibly each MADV_DONTNEED
>>> sycall invocation slower.
>>
>> Maybe just mark the vma, and then scan it in the system reclaim path.
>>
>> I also plan to do this in the MADV_FREE case, instead of adding an
>> asynchronous madvise option first.
>>
>>>
>>> (1) would already help a lot and showcase how the locking/machinery
>>> would work.
>>>
>>>
>>>> b. for MADV_FREE case:
>>>>
>>>>      - add a madvise option for synchronous reclaim
>>>>
>>>>      - add another madvise option to mark the vma, then add its
>>>>              corresponding mm to a global list, and then traverse
>>>>              the list and reclaim it when the memory is tight and
>>>>              enters the system reclaim path.
>>>>              (maybe there is an option to unmark)
>>>>
>>>> c. for s390 case you mentioned, create a CONFIG_FREE_PT first, and
>>>>       then s390 will not select this config until the problem is 
>>>> solved.
>>>>
>>>> d. for lockless scan, try using disabling IRQ or (mmap read lock +
>>>> pte_offset_map_nolock).
>>>
>>> Although d) really only is desired when scanning asynchronously I think.
>>> During (1) above, we know that the table will be very likely empty
>>> (unless weird race).
>>
>> Agree.
> 
> Again, thanks for working on this. Let me know (can also do privately) 
> if you run into any issues or think I can be of help. :)

That's great, thank you very much!

>