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

From: Sergey Senozhatsky

Date: Wed Oct 21 2026 - 22:56:35 EST


On (26/10/16 09:09), Nhat Pham wrote:
> 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.

Right, especially interesting what happens if OOM-kill of an app with
a considerable amount of data stored in zsmalloc pool, is not immediately
easing the memory pressure.

[..]
> If it's the former, we should dedicate more time
^^^^
and tokens ;)
> towards improving zsmalloc.