On Fri, Dec 06, 2024 at 12:30:54AM +0000, Wei Yang wrote:
> 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
Yes
>
> >
> >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.
Mel's tests also pull in from the will-it-scale project [0], which these brk
tests I'm referring to originate. The mmtest logic just performs some
statistical analysis and comparisons etc. across a number of different test
sources.
[0]:https://github.com/antonblanchard/will-it-scale
>
> >>
> >>
> >> --
> >> Wei Yang
> >> Help you, Help me
>
> --
> Wei Yang
> Help you, Help me
