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

On 8/12/2026 12:25 AM, Nhat Pham wrote:
> On Tue, Aug 11, 2026 at 2:04 AM Xueyuan Chen <[email protected]> wrote:
>>
>> On 8/8/2026 12:25 AM, Nhat Pham wrote:
>>> On Fri, Aug 7, 2026 at 5:12 AM Sergey Senozhatsky
>>> <[email protected]> wrote:
>>>> On (26/08/07 18:57), Xueyuan Chen wrote:
>>>>> 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?
>>>> Let's bring in heavy artillery to this discussion, in addition to Andrew
>>>> 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).
>>> Hmm we'd need to collect more data in our workloads to determine, but
>>> 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.
>> Hi Nhat,
>>
>> 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.
> What's the distribution of these? Say if I were to skip all size class
> 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?).
Hi Nhat,

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