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

[Wei Yang <richard.weiyang@gmail.com>]

On Wed, May 14, 2025 at 01:23:18AM +0000, Wei Yang wrote:
>On Wed, Apr 30, 2025 at 09:47:16AM +0200, David Hildenbrand wrote:
>[...]
>>> > > Agreed, skimming over the tests there are some nice diagrams and cases.
>>> > > 
>>> > > But I would hope that for most of these cases we could test on a higher
>>> > > level: test our expectations when running real programs that we want to
>>> > > check, especially when performing internal changes on how we handle anon
>>> > > memory + rmap.
>>> > > 
>>> > > E.g., do fork(), then test if we can successfully perform rmap
>>> > > lookups/updates (e.g., migrate folio to a different numa node etc).
>>> > > 
>>> > 
>>> > That's a great point! Wei - if you could look at making some self-tests
>>> > (i.e. that live in tools/testing/selftests/mm) that try to recreate _real_
>>> > scenarios that use the rmap like this and assert correct behaviour there,
>>> > that could be a positive way of moving forward with this.
>>> > 
>>> 

Ping

>>> 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)
>
>>
>>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 ?
>
>But we need to enable pageout in this way first.
>
>I am not sure why this one is easier way to test. Would you mind sharing more
>idea on this?
>
>>Some rmap tests could make sense for both, anon and pagecache folios.
>>
>>> 
>>> Something like below?
>>> 
>>>    * fork and migrate a range in child
>>>    * fork/unmap in parent and migrate a range in child
>>> 
>>> If the operation is successful, then we are good, right?
>>
>>Yes. And one can come up with a bunch of similar rmap test cases, like doing
>>a partial mremap() of a THP, then testing if the rmap walk still works as
>>expected, pairing the whole thing with for etc.
>>
>
>For both way, we could arrange all those scenarios and also do partial
>mremap() during it. 
>
>>One "problem" here is that even with MPOL_MF_MOVE_ALL,
>>move_pages() will not move a folio if it already resides on the target node.
>>So one always needs two NUMA nodes, which is a bit suboptimal for testing
>>purposes.
>>
>>For testing purposes, it could have been helpful a couple of times already to
>>just have a way of migrating a folio even if it already resides on the
>>expected node.
>>
>
>This looks we need a new flag for it?
>
>Here is my plan if my understanding is correct.
>
>1. Add test cases for fork + migrate. We may limit it only works on machine
>   with 2 NUMA nodes.
>2. Enable move_pages() on local node, then remove the test limitation
>3. Enable madvise(MADV_PAGEOUT) with multiple mapping, then add related cases
>4. Add mremap() or other cases
>
>In general, to verify rmap dose the work correctly, my idea is to
>
>  * mmap(MAP_SHARED)
>  * write some initial data before fork
>  * after fork and migrate, we write some different data to it
>  * if each process do see the new data, rmap is good.
>
>Does it sound good to you?
>
>>-- 
>>Cheers,
>>
>>David / dhildenb
>
>-- 
>Wei Yang
>Help you, Help me

-- 
Wei Yang
Help you, Help me