Re: [PATCH 0/3] mm: remove zpool

[Vlastimil Babka <vbabka@suse.cz>]

On 9/4/25 11:33, Vitaly Wool wrote:
>> With zswap using zsmalloc directly, there are no more in-tree users of
>> this code. Remove it.
>> 
>> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> 
> Per the previous discussions, this gets a *NACK* from my side. There is
> hardly anything _technical_ preventing new in-tree users of zpool API.
> zpool API is neutral and well-defined, I don’t see *any* good reason for
> it to be phased out.

AFAIK it's a policy that unused code should be removed ASAP. And that's the
case for zpool after Patch 1, no? It could be different if another user was
about to be merged (to avoid unnecessary churn), but that doesn't seem the
case for zblock?

My concern would be if the removal breaks any existing installations relying
on zswap. Presumably not as a make oldconfig will produce a config where
nothing important is missing, and existing boot options such as
"zswap.zpool=" or attempts to write to in the init scripts to
"/sys/module/zswap/parameters/zpool" will cause some errors/noise but not
prevent booting correctly?

I mean if we were paranoid and anticipated somebody would break their
booting if writing to /sys/module/zswap/parameters/zpool failed, we could
keep the file (for a while) and just produce a warning in dmesg that it's
deprecated and does nothing?

From Patch 1:

> Note that this does not preclude future improvements and experiments
> with different allocation strategies. Should it become necessary, it's
> possible to provide an alternate implementation for the zsmalloc API,
> selectable at compile time. However, zsmalloc is also rather mature
> and feature rich, with years of widespread production exposure; it's
> encouraged to make incremental improvements rather than fork it.

With my history of maintaining the slab allocators I can only support this
approach.


> BTW, remarkable is that you didn't bother to CC: me to this patch.
> 
> Anyway,
> 
> Nacked-by: Vitaly Wool <vitaly.wool@konsulko.se>
>