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

[Hongfeng Chen <chenhongfeng0212@163.com>]

Hi Nhat,

On Fri, Oct 16, 2026 at 9:09 AM Nhat Pham <nphamcs@gmail.com> 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.

> 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.

> 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:

--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1455,6 +1455,8 @@ void zs_free(struct zs_pool *pool, unsigned long handle)
 	int fullness;
 	struct zspage *zspage_to_free = NULL;
 
+	return;
+
 	if (IS_ERR_OR_NULL((void *)handle))
 		return;

The speedup is as follows:

  machine                   base      with-diff-above   speedup
  x86, 1024 MB              50.2 ms   20.6 ms           2.44x
  RK3588 A76, 1024 MB       89.4 ms   23.3 ms           3.84x

Thanks,
Hongfeng