Re: [RFC PATCH 0/2] mm: zsmalloc: make shrinker compaction budget-aware

Hi Sergey,

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?

Thanks,
Xueyuan


On 8/7/2026 11:56 AM, Sergey Senozhatsky wrote:
> On (26/08/06 16:27), [email protected] wrote:
>> On an Android device with 12 GB of RAM, observed zsmalloc compaction
>> durations had a p95 of 38.86 ms and a maximum of 269.68 ms, motivating a
>> per-scan reclaim goal.
> Would it be possible to give a little more data?  What was the
> fragmentation ratio, how much memory was saved during that
> auto-compaction, etc.  If possible.
>
> Somewhere in the back of my mind I was thinking about, maybe,
> disabling (removing) zsmalloc shrinker callbacks, in other words
> disabling auto-compaction.  We have a sysfs knob for pool compaction
> for system that still want to run compaction.  So I'm leaning towards
> removal of shrinker callbacks from zsmalloc.