| Message ID | cover.1733248985.git.lorenzo.stoakes@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm/vma: make more mmap logic userland testable | expand |
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? >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?
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) You'd not really expect an impact based on relocation of this code, but with brk it's always worth checking... > > > -- > Wei Yang > Help you, Help me
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
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
This series carries on the work the work started in previous series and 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. The stack expansion logic is also moved into mm/vma.c, which necessitates a change in the API exposed to the exec code, removing the invocation of the expand_downwards() function used in get_arg_page() and instead adding mmap_read_lock_maybe_expand() to wrap this. Lorenzo Stoakes (5): mm/vma: move brk() internals to mm/vma.c mm/vma: move unmapped_area() internals to mm/vma.c mm: abstract get_arg_page() stack expansion and mmap read lock mm/vma: move stack expansion logic to mm/vma.c mm/vma: move __vm_munmap() to mm/vma.c fs/exec.c | 14 +- include/linux/mm.h | 5 +- mm/mmap.c | 469 ++++-------------------------- mm/vma.c | 478 ++++++++++++++++++++++++++++--- mm/vma.h | 20 +- tools/testing/vma/vma.c | 11 + tools/testing/vma/vma_internal.h | 152 ++++++++++ 7 files changed, 681 insertions(+), 468 deletions(-) -- 2.47.1