Thread (19 messages) 19 messages, 6 authors, 2024-01-24

Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED

From: Yosry Ahmed <hidden>
Date: 2024-01-16 20:20:21
Also in: linux-mm, loongarch

On Tue, Jan 16, 2024 at 7:39 AM Christoph Hellwig [off-list ref] wrote:
On Fri, Jan 12, 2024 at 04:38:30PM -0800, Nhat Pham wrote:
quoted
quoted
I thought deprecating z3fold is the low hanging fruit. Then, once we
can sort out the MMU dependency in zsmalloc, we can go after zbud as
well.
Makes sense to me. Should we do the same thing to zbud? We probably
have even less of a case for it, no?
Is there any user visible effect of switching the allocator?  If not it
seems a bit pointless to deprecate them vs just removing them (or maybe
making z3fold depend on !MMU for now).
Well, better compression ratios for one :)

I think a long time ago there were complaints that zsmalloc had higher
latency than zbud/z3fold, but since then a lot of things have changed
(including nice compaction optimization from Sergey, and compaction
was one of the main factors AFAICT). Also, recent experiments that
Chris Li conducted showed that (at least in our setup), the
decompression is only a small part of the fault latency with zswap
(i.e. not the main factor) -- so I am not sure if it actually matters
in practice.

That said, I have not conducted any experiments personally with z3fold
or zbud, which is why I proposed the conservative approach of marking
as deprecated first. However, if others believe this is unnecessary I
am fine with removal as well. Whatever we agree on is fine by me.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help