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

[Nhat Pham]

On Fri, Oct 23, 2026 at 5:39 AM Hongfeng Chen <chenhongfeng0212@xxxxxxx> wrote:
>
> Hi Nhat,
>
> On Fri, Oct 16, 2026 at 9:09 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> > 1. Would memory freeing be slowed down?
>
> I sampled pool->pages_allocated every 1 ms, and measured the time from
> the start of munmap() until the zspages are freed. Three cases are
> tested: 1 process x 256MB, 1 process x 1024MB, and 4 processes x
> 256MB. The results are as follows:
>
>   workload                  base      with-patch
>   1 process, 256 MB         14 ms     9 ms
>   1 process, 1024 MB        51 ms     31 ms
>   4 processes, 256 MB       45 ms     24 ms
>
> Memory freeing didn't get slower and it actually got faster.

Neat! Thanks for double checking! I assume this is because we're doing
memory reclamation in parallel with the extra kworker thread?

Which brings me to the next point:

>
> > 2. Would this introduce isolation issues, especially when this work is
> > not properly accounted?
>
> Yes. The drain runs in an unbound kworker in the root cgroup, so its
> cost is not charged to the killed tenant, and it may take CPU time
> from other tenants. I'd appreciate any suggestions on a clean way to
> handle this.

I don't have a good solution either... This has been a blocker for
other work offloading idea too.

+Shakeel, who might have some ideas on this.

But before we do this:

>
> > 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
>
> Mostly zsmalloc. I kept the footprint the same (1 GB paged out to zram,
> then munmap()) and only made zs_free() do nothing:

Is there any more juice we can squeeze from zsmalloc in that case?

It would be nice if you can perf zsmalloc freeing. And yeah, maybe we
can't optimize any further, but let's eliminate that first before we
rely on offloading.