On Tue, Jun 25, 2024 at 3:32 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > On Tue, Jun 25, 2024 at 1:11 AM Alex Shi <seakeel@xxxxxxxxx> wrote: > > > > Thanks a lot for the info and comments! It's my stupid w/o checking the email list before work on it. > > Anyway don't know if z3fold would be removed, jut left this tested patchset here if someone need it. > > It's partially our fault for leaving z3fold knowing that it is headed > toward deprecation/removal. FWIW, I tried to remove it or mark it as > deprecated, but there was some resistance :/ > Our apologies, Alex. Thank you for your contribution regardless! Regarding zbud and z3fold, this is the second time this conversation has come up within a week or so. Chengming was trying to revert the multiple zpool changes. zsmalloc (after we re-introduce the class locks) does not seem to regress (at least based on benchmarking), but z3fold and zbud suffer. I think we are starting to pay the price of maintaining z3fold and zbud: 1. Future improvement to related subsystems now hurts z3fold. Developers/maintainers have to spend extra mental capacity to consider this, and users could potentially see worse performance if they select z3fold/zbud unknowingly. 2. Contributors are confused on where they should spend their effort on improving. Can we at least have a roadmap for deprecating these 2? Something along the line of: 1. Deprecate either zbud or z3fold. We do not really need both of them. 2. Make zsmalloc independent of MMU, somehow (IIRC, compaction was one reason right? maybe making zsmalloc compaction dependent on MMU availability?). 3. Deprecate the remaining one - zsmalloc can be used in all deployments now. 4. (Optional) Maybe adding another allocator for the edge cases that zsmalloc does not handle well? I'd need to see numbers to be convinced that this is the case. I think I saw somewhere that Vitaly was working on zblock - look forward to seeing this :)
