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

[Hongfeng Chen <chenhongfeng0212@gmail.com>]

From: Hongfeng Chen <chenhongfeng0212@163.com>

On Fri, Oct 23, 2026 at 11:19 AM Nhat Pham <nphamcs@gmail.com> wrote:
> 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.

Here is the perf breakdown of the free path:

zram:

  __swap_cluster_free_entries        90.28%
    zram_slot_free_notify            86.01%
      slot_free                      74.15%
        zs_free                      56.01%
          __free_frozen_pages        19.85%
          kmem_cache_free            10.15%
          _raw_spin_lock              5.53%
          fix_fullness_group          3.31%
          dec_zone_page_state         2.43%
          obj_free                    2.17%
          trylock_zspage              2.12%

zswap:

  __swap_cluster_free_entries        94.30%
    zswap_invalidate                 93.49%
      zswap_entry_free               73.76%
        zs_free                      34.03%
          __free_frozen_pages        11.13%
          kmem_cache_free             5.57%
          fix_fullness_group          2.66%
          _raw_spin_lock              2.45%
          trylock_zspage              1.75%
          dec_zone_page_state         1.67%
          obj_free                    0.96%
        obj_cgroup_uncharge_zswap    13.90%
        list_lru_del                 11.73%
        kmem_cache_free               4.62%
      xa_erase                       19.27%

Most of zs_free() is returning memory: empty zspages, handles and
zspage slab objects. So returning memory cannot be avoided, it can
only be batched or deferred.

In zram, zs_free() is 56% of the time, so deferring only zs_free()
can speed up munmap() by at most about 2.3x. In zswap, zs_free() is
34% of the time, so the speed up limit is about 1.5x.

That leaves two places to go further.

1. Async freeing at or above __swap_cluster_free_entries()

Deferring at or above __swap_cluster_free_entries() covers zram and
zswap with one mechanism.

2. Optimizing zram alone

For zram I would rather go back to v1 [1], which defers in zram. v1
also uses a single gc_work per device to offer a best-effort service,
which greatly reduces the impact of the unbound worker on other
tenants.


[1] https://lore.kernel.org/linux-mm/20260412060450.15813-1-baohua@kernel.org/

Thanks,
Hongfeng