Re: [RFC Patch 0/5] Make anon_vma operations testable

[David Hildenbrand <david@redhat.com>]

On 30.05.25 16:05, Wei Yang wrote:
> On Fri, May 30, 2025 at 10:00:18AM +0200, David Hildenbrand wrote:
> [...]
>>>>
>>>> Thanks for reminding me and sorry for the late reply.
>>>>
>>>>>
>>>>>>>> I am trying to understand what scenarios you want.
>>>>>>>
>>>>>>
>>>>>> Sorry for the late reply, I handled other things a while.
>>>>>>
>>>>>>> That is exactly the task to figure out: how can we actually test our rmap
>>>>>>> implementation from a higher level. The example regarding fork and migration
>>>>>>> is possibly a low-hanging fruit.
>>>>>>
>>>>>> If my understanding is correct, you suggested two high level way:
>>>>>>
>>>>>> 1. fork + migrate (move_pages)
>>>>
>>>> Yes, that should be one way of testing it. We could even get multiple child
>>>> processes into place.
>>>>
>>>>>>
>>>>>>>
>>>>>>> We might already have the functionality to achieve it, *maybe* we'd even want
>>>>>>> some extensions to make it all even easier to test.
>>>>>>>
>>>>>>> For example, MADV_PAGEOUT is refused on folios that are mapped into multiple
>>>>>>> processes. Maybe we'd want the option to *still* page it out, just like
>>>>>>> MPOL_MF_MOVE_ALL allows with CAP_SYS_NICE to *still* migrate a folio that is
>>>>>>> mapped into multiple processes.
>>>>>>>
>>>>>>
>>>>>> 2. madvise(MADV_PAGEOUT)
>>>>>>
>>>>>> Not fully get it here. You mean fork + madvise(MADV_PAGEOUT) + migrate ?
>>>>
>>>> fork + madvise(MADV_PAGEOUT) only.
>>>>
>>>> Then verify, that it was actually paged out.
>>>>
>>>> For example, we could have 10 processes mapping the page, then call
>>>> madvise(MADV_PAGEOUT) from one process. We can verify in all processes if the
>>>> page is actually no longer mapped using /proc/self/pagemap
>>>>
>>>
>>> Hi, David
>>
>> Hi!
>>
>>>
>>> I'd like to clarify some detail here.
>>>
>>>> We could likely do it with anon pages (swap), shmem pages (swap) and
>>>> pagecache pages (file backed).
>>>>
>>>
>>> I could understand the three cases here, but for the (swap) case, it is not
>>> clear to me. You mean we force the page to be swapped out before migration? I
>>> may not have an idea to ensure that.
>>
>> No need to involve migration for that test. It's sufficient to trigger
>> pageout to then check if the page was unmapped in all other processes.
>>
> 
> Here you mean for all anon/shmem/pagecache pages, we could have two category
> tests:
> 
>    * migrate and write different data from on process, verify each process see
>      new data
>    * trigger pageout from one process, verify each process has it pageout
>      (/proc/self/pagemap)
> 
> While one of these category is enough, right? Just like KSM below, migrate or
> pageout.

Both cases will trigger different code paths: for example, migration 
will trigger restoring of migration entries, which is a different rmap 
operation not triggered by pageout/pagein :)

Pageout is probably easier to implement: but we couldn't test hugetlb. 
With migration we probably could also test hugetlb rmap code (yet 
another case we should probably cover).

-- 
Cheers,

David / dhildenb