Re: [RFC PATCH v4 0/2] mm/zsmalloc: defer object free to per-cpu batches

[Nhat Pham]

On Fri, Oct 16, 2026 at 5:10 AM Hongfeng Chen
<chenhongfeng0212@xxxxxxxxx> wrote:
>
> Performance results:
>
> ROCK 5B+ (RK3588: 4x Cortex-A55 at 1.8GHz, 4x Cortex-A76 at 2.4GHz,
> performance governor), single process munmap on A55:
>
>   times in ms, speedups over base
>               Base       Patch1       Patch1+2
>   size        time    time speedup   time speedup
>   64MB       13.81    3.62   3.81x   3.28   4.21x
>   128MB      28.50    7.18   3.97x   6.49   4.39x
>   192MB      42.19   10.71   3.94x   9.69   4.36x
>   256MB      56.06   14.26   3.93x   12.89  4.35x
>   512MB     109.50   28.43   3.85x   25.66  4.27x
>   1024MB    217.10   56.70   3.83x   51.15  4.24x
>
> Same machine, single process munmap on A76:
>
>   times in ms, speedups over base
>               Base       Patch1        Patch1+2
>   size        time    time speedup    time speedup
>   64MB        5.59    1.58   3.54x    1.49   3.76x
>   128MB      11.86    3.16   3.75x    2.95   4.02x
>   192MB      17.18    4.72   3.64x    4.45   3.86x
>   256MB      22.89    6.29   3.64x    5.87   3.90x
>   512MB      45.15   12.52   3.61x   11.64   3.88x
>   1024MB     89.16   24.75   3.60x   23.12   3.86x
>
> x86 (Intel Core i7-14700HX, P-cores locked at 2.1GHz with turbo off),
> single process munmap:
>
>   times in ms, speedups over base
>               Base       Patch1         Patch1+2
>   size        time    time speedup    time speedup
>   64MB        2.87    1.50   1.92x    1.14   2.53x
>   128MB       6.00    2.93   2.05x    2.21   2.71x
>   192MB       9.33    4.35   2.15x    3.33   2.80x
>   256MB      12.51    5.78   2.17x    4.38   2.85x
>   512MB      24.96   11.39   2.19x    8.62   2.90x
>   1024MB     50.19   22.78   2.20x   17.05   2.94x
>
> 1-4 process munmap of 256MB each:
>
>   times in ms, speedups over base
>               Base       Patch1        Patch1+2
>   mode        time    time speedup   time speedup
>   1p         13.18    5.78   2.28x   4.35   3.03x
>   2p         25.83   14.41   1.79x   4.57   5.65x
>   3p         35.70   22.14   1.61x   4.68   7.63x
>   4p         44.25   28.71   1.54x   4.75   9.31x

The numbers look nice, but I think it's a given that if we measure the
process whose work is offloaded, we'll see a speedup.

But would this come at a cost?

1. Would memory freeing be slowed down? Could you compare the host
memory usage over this period of time etc.? Hopefully the parallelism
would cancel out the extra overhead of setting up the work offloading.

2. Would this introduce isolation issues, especially when this work is
not properly accounted? Say you have a busy-ish host, with multiple
tenants. One of them is killed. With this new mechanism, would this
affect the performance of other tenants? (for e.g if we need more
cycles for the async overhead, or if memory is released slower overall
as stated above, etc.)

Some more benchmarking to show this would be nice!

Another thing I wonder is, how much of this slowed down is because of
zsmalloc's own inefficiency, and how much is because we just have a
larger logical footprint because compressing memory allows us to
allocate more. If it's the former, we should dedicate more time
towards improving zsmalloc. If it's the latter (or if fixing zsmalloc
is just not possible) then yeah maybe parallelism/work offloading is
the answer. An interesting setup would be, turning of zsmalloc, but
allocate just as much memory (logically-speaking), then kill the
process and sees if you observe the same slow down.