Re: [PATCH v10 0/5] Introduce mseal

Jeff Xu
2024-04-16T19:40:38Z

On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * jeffxu@chromium.org <jeffxu@chromium.org> [240415 12:35]:
> > From: Jeff Xu <jeffxu@chromium.org>
> >
> > This is V10 version, it rebases v9 patch to 6.9.rc3.
> > We also applied and tested mseal() in chrome and chromebook.
> >
> > ------------------------------------------------------------------
> ...
>
> > MM perf benchmarks
> > ==================
> > This patch adds a loop in the mprotect/munmap/madvise(DONTNEED) to
> > check the VMAs’ sealing flag, so that no partial update can be made,
> > when any segment within the given memory range is sealed.
> >
> > To measure the performance impact of this loop, two tests are developed.
> > [8]
> >
> > The first is measuring the time taken for a particular system call,
> > by using clock_gettime(CLOCK_MONOTONIC). The second is using
> > PERF_COUNT_HW_REF_CPU_CYCLES (exclude user space). Both tests have
> > similar results.
> >
> > The tests have roughly below sequence:
> > for (i = 0; i < 1000, i++)
> > create 1000 mappings (1 page per VMA)
> > start the sampling
> > for (j = 0; j < 1000, j++)
> > mprotect one mapping
> > stop and save the sample
> > delete 1000 mappings
> > calculates all samples.
>
>
> Thank you for doing this performance testing.
>
> >
> > Below tests are performed on Intel(R) Pentium(R) Gold 7505 @ 2.00GHz,
> > 4G memory, Chromebook.
> >
> > Based on the latest upstream code:
> > The first test (measuring time)
> > syscall__ vmas t t_mseal delta_ns per_vma %
> > munmap__ 1 909 944 35 35 104%
> > munmap__ 2 1398 1502 104 52 107%
> > munmap__ 4 2444 2594 149 37 106%
> > munmap__ 8 4029 4323 293 37 107%
> > munmap__ 16 6647 6935 288 18 104%
> > munmap__ 32 11811 12398 587 18 105%
> > mprotect 1 439 465 26 26 106%
> > mprotect 2 1659 1745 86 43 105%
> > mprotect 4 3747 3889 142 36 104%
> > mprotect 8 6755 6969 215 27 103%
> > mprotect 16 13748 14144 396 25 103%
> > mprotect 32 27827 28969 1142 36 104%
> > madvise_ 1 240 262 22 22 109%
> > madvise_ 2 366 442 76 38 121%
> > madvise_ 4 623 751 128 32 121%
> > madvise_ 8 1110 1324 215 27 119%
> > madvise_ 16 2127 2451 324 20 115%
> > madvise_ 32 4109 4642 534 17 113%
> >
> > The second test (measuring cpu cycle)
> > syscall__ vmas cpu cmseal delta_cpu per_vma %
> > munmap__ 1 1790 1890 100 100 106%
> > munmap__ 2 2819 3033 214 107 108%
> > munmap__ 4 4959 5271 312 78 106%
> > munmap__ 8 8262 8745 483 60 106%
> > munmap__ 16 13099 14116 1017 64 108%
> > munmap__ 32 23221 24785 1565 49 107%
> > mprotect 1 906 967 62 62 107%
> > mprotect 2 3019 3203 184 92 106%
> > mprotect 4 6149 6569 420 105 107%
> > mprotect 8 9978 10524 545 68 105%
> > mprotect 16 20448 21427 979 61 105%
> > mprotect 32 40972 42935 1963 61 105%
> > madvise_ 1 434 497 63 63 115%
> > madvise_ 2 752 899 147 74 120%
> > madvise_ 4 1313 1513 200 50 115%
> > madvise_ 8 2271 2627 356 44 116%
> > madvise_ 16 4312 4883 571 36 113%
> > madvise_ 32 8376 9319 943 29 111%
> >
>
> If I am reading this right, madvise() is affected more than the other
> calls? Is that expected or do we need to have a closer look?
>
The madvise() has a bigger percentage (per_vma %), but it also has a
smaller base value (cpu).

-Jeff