Re: [PATCH 0/5] mm/vma: make more mmap logic userland testable

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

On Thu, Dec 05, 2024 at 07:03:08AM +0000, Lorenzo Stoakes wrote:
>On Wed, Dec 04, 2024 at 11:56:32PM +0000, Wei Yang wrote:
>> On Tue, Dec 03, 2024 at 06:05:07PM +0000, Lorenzo Stoakes wrote:
>> >This series carries on the work the work started in previous series and
>>                         ^^^      ^^^
>>
>> Duplicated?
>
>Thanks yes, but trivial enough that I'm not sure it's worth a
>correction. Will fix if need to respin.
>
>>
>> >continued in commit 52956b0d7fb9 ("mm: isolate mmap internal logic to
>> >mm/vma.c"), moving the remainder of memory mapping implementation details
>> >logic into mm/vma.c allowing the bulk of the mapping logic to be unit
>> >tested.
>> >
>> >It is highly useful to do so, as this means we can both fundamentally test
>> >this core logic, and introduce regression tests to ensure any issues
>> >previously resolved do not recur.
>> >
>> >Vitally, this includes the do_brk_flags() function, meaning we have both
>> >core means of userland mapping memory now testable.
>> >
>> >Performance testing was performed after this change given the brk() system
>> >call's sensitivity to change, and no performance regression was observed.
>>
>> May I ask what performance test is done?
>
>mmtests brk1, brk2 (will-it-scale)

The one from here ?

https://github.com/gormanm/mmtests

>
>You'd not really expect an impact based on relocation of this code, but
>with brk it's always worth checking...
>

Yes, I am trying to know usually what perform test we would use.

>>
>>
>> --
>> Wei Yang
>> Help you, Help me

-- 
Wei Yang
Help you, Help me