[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16998440-84fb-45a4-9134-5dcff71ee68d@konsulko.se>
Date: Sat, 6 Sep 2025 00:20:47 +0200
From: Vitaly Wool <vitaly.wool@...sulko.se>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: hannes@...xchg.org, linux-kernel@...r.kernel.org,
Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org
Subject: Re: [PATCH 0/3] mm: remove zpool
On 9/5/25 20:30, Andrew Morton wrote:
> On Fri, 5 Sep 2025 07:42:34 +0200 Vitaly Wool <vitaly.wool@...sulko.se> wrote:
>
>>
>>
>> On 9/5/25 01:47, Andrew Morton wrote:
>>> On Thu, 4 Sep 2025 11:33:24 +0200 Vitaly Wool <vitaly.wool@...sulko.se> wrote:
>>>
>>>>> With zswap using zsmalloc directly, there are no more in-tree users of
>>>>> this code. Remove it.
>>>>>
>>>>> Signed-off-by: Johannes Weiner <hannes@...xchg.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.
>>>
>>> Well, we have the zpool code and we know it works. If a later need for
>>> the zpool layer is demonstrated then we can unremove the code at that
>>> time.
>>
>> The whole patchset [1] depends on zpool, with the whole intention to use
>> it on the Rust side.
>>
>> [1] https://lkml.org/lkml/2025/8/23/232
>
> Well, that puts a Rust wrapper around zpool. But what user-visible
> benefit does it (or shall it) enable?
There's at least one user ([2]) of that interface in the pipeline.
[2] https://github.com/vwool/linux-mm/blob/rbtree_experiment/mm/zblock.rs
Powered by blists - more mailing lists