Re: [RFC PATCH 0/2] mm: zsmalloc: make shrinker compaction budget-aware
From: Xueyuan Chen
Date: Tue Aug 18 2026 - 08:11:22 EST
On 8/12/2026 12:25 AM, Nhat Pham wrote:
On Tue, Aug 11, 2026 at 2:04 AM Xueyuan Chen <xueyuan.chen@xxxxxxxx> wrote:Hi Nhat,
What's the distribution of these? Say if I were to skip all size class
On 8/8/2026 12:25 AM, Nhat Pham wrote:
On Fri, Aug 7, 2026 at 5:12 AM Sergey SenozhatskyHi Nhat,
<senozhatsky@xxxxxxxxxxxx> wrote:
On (26/08/07 18:57), Xueyuan Chen wrote:Hmm we'd need to collect more data in our workloads to determine, but
Hi Sergey,Let's bring in heavy artillery to this discussion, in addition to Andrew
Here is some additional data:
I used the following definitions:
compactable ratio = freeable_pages / total_pages
memory reclaimed = pages_freed * PAGE_SIZE
freeable_pages is the estimate before compaction, based on the same
calculation as zs_shrinker_count(), while pages_freed is the actual
number of backing pages released.
There were 264 callbacks in the trace:
callback elapsed time:
median: 5.77 ms
p95: 55.82 ms
maximum: 271.36 ms
compactable ratio before compaction:
median: 0.32%
p95: 2.86%
maximum: 8.33%
memory reclaimed per callback:
median: 3.80 MiB
p95: 30.45 MiB
maximum: 92.73 MiB
The longest callback took 271.36 ms. Its compactable ratio was 3.25%,
and it released 7,650 pages, or about 29.88 MiB.
There was also a 241.91 ms callback (with 30 schedule-outs) with a
compactable ratio of 0.44%. It released 1,019 pages, or about
3.98 MiB.
Based on this data, it seems better to remove the shrinker.
Would you prefer that I change v2 to remove the zsmalloc shrinker
callbacks directly?
and Minchan, adding Nhat, Yosry, Barry, Johannes, Brian (random order).
Folks, I'm bullish on removal of zsmalloc shrinker callbacks.
I don't think those buy us much apart from memcpy-s and lock
contention. Systems that want to compact zsmalloc have a sysfs
knob (and API) to do so (based on zram mm_stat numbers).
if we can compute compactable ratio (freeable_pages / total_pages) on
a per size class basis, can we just skip the size class whose ratio is
too bad? Would that at least cut down on the vast majority of
fruitless memcpys and lock acquisitions etc?
I'm always a bit hesitant to over-rely on userspace, especially when
kernel has information to do something smart about it. It might not
react in time, and many proactive reclaiming schemes back off under
heavy memory pressure.
I collected per size-class data. 53.7% of size classes have freeable==0,
so skipping them saves some time. However, 94.7% of zs_compact() time is
spent on classes where freeable > 0 — meaning the cost is dominated by
the actual compaction work, not by scanning empty classes.
with compactable ratio below 20%, or those where we can free at least
one full zspage? (IIUC, we only free any memory at all if a zspage got
freed up from our internal compaction, correct?).
Across 106 zram0 compaction callbacks, there were 6,246 per-class
events with freeable > 0, covering 118 size classes.
The data by object size was:
| object size (bytes) | classes | events | total pages | freeable pages |
| [0, 256) | 14 | 570 | 182297 | 6728 |
| [256, 512) | 16 | 748 | 480127 | 14526 |
| [512, 1024) | 30 | 1586 | 2677075 | 71934 |
| [1024, 2048) | 36 | 2180 | 11990170 | 294133 |
| [2048, 3072) | 15 | 821 | 5089301 | 106204 |
| [3072, 4096] | 7 | 341 | 1170843 | 20012 |
The compactable-ratio distribution at class-compaction entry was:
p25: 0.75%
median: 1.65%
p90: 6.76%
p95: 9.42%
p99: 14.52%
maximum: 30.99%
Only 12 out of 6,246 events had a ratio of 20% or higher, so a 20%
threshold would skip nearly all of them.
| freeable pages | total pages | compactable ratio |
class A | 10 | 20 | 50% |
class B | 20 | 50 | 40% |
In this example, class B has more freeable pages even though its ratio
is lower. So I don't think the ratio alone is enough to decide whether
to compact a class.
Thanks,
Xueyuan