Re: [PATCH v4 0/2] rust: zpool: add abstraction for zpool drivers

[Vlastimil Babka <vbabka@suse.cz>]

On 8/26/25 16:56, Vitaly Wool wrote:
> 
> 
>> On Aug 26, 2025, at 2:44 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
>> 
>> On Sat, Aug 23, 2025 at 03:04:19PM +0200, Vitaly Wool wrote:
>>> Zpool is a common frontend for memory storage pool implementations.
>>> These pools are typically used to store compressed memory objects,
>>> e. g. for Zswap, the lightweight compressed cache for swap pages.
>>> 
>>> This patch provides the interface to use Zpool in Rust kernel code,
>>> thus enabling Rust implementations of Zpool allocators for Zswap.
>> 
>> The zpool indirection is on its way out.
>> 
>> When you submitted an alternate allocator backend recently, the
>> resounding feedback from the zswap maintainers was that improvements
>> should happen to zsmalloc incrementally. It is a lot of code and has a
>> lot of features that go beyond allocation strategy. We do not want to
>> fork it and fragment this space again with niche, incomplete backends.
>> 
>> It's frustrating that you not only ignored this, but then went ahead
>> and made other people invest their time and effort into this as well.
>> 
> 
> I don’t think we have a consensus on that.
> 
> And zblock is, after some additional improvements, just better than
> zsmalloc in all meaningful aspects, let alone the simplicity. It is fas
> easier to implement in Rust than zsmalloc, too. Besides, zram is a good
> candidate to be rewritten in Rust as well and after that is done, zblock

If your target is zram (not zswap) then I don't understand why insist on the
zpool layer, as zram refused to adopt it in the first place?

> will be even safer and faster. So while not being “incomplete", it’s
> zsmalloc that is becoming a niche backend moving forward, and I would
> argue that it could make more sense to eventually obsolete *it* rather
> than the zpool API.
> 
> ~Vitaly