Re: Confusing olddefault prompt for Z3FOLD

[Michal Hocko]

On Thu 28-04-16 21:40:48, Vitaly Wool wrote:
> On Thu, Apr 28, 2016 at 1:58 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> > On Thu 28-04-16 13:35:45, Vitaly Wool wrote:
[...]
> >> * zbud is 30% less object code
> >
> > This sounds like a lot but in fact:
> >    text    data     bss     dec     hex filename
> >    2063     104       8    2175     87f mm/zbud.o
> >    3467     104       8    3579     dfb mm/z3fold.o
> 
> I get significantly larger code on an ARM64 machine...

That is quite unexpected. I would assume that the arch specific growth
would be proportional for both modules.

[...]

> >> * zbud exports its own API while z3fold is designed to work via zpool
> >
> > $ git grep EXPORT mm/zbud.c include/linux/zbud.h
> > $
> >
> > So the API can be used only from the kernel, right? I haven't checked
> > users but why does the API actually matters.
> >
> > Or is there any other API I have missed.
> 
> Not sure really. zswap used to call zbud functions directly rather
> than via zpool. z3fold was only intended to be used via zpool. That of
> course may be changed, but I consider it right to have something
> proven and working side-by-side with the new stuff and if the new
> stuff supersedes the old one, well, we can remove the latter later.

On the other hand it is more code to maintain. I can see a reason to
have more implementations if they are not overlapping completely - e.g.
because they behave really differently for specific usecases which are
too hard to be covered by a single algorithm. Is this the case here?
If yes this should be really explained and justified. I really hate how
all the Z* stuff is hard to grasp because there are way too many
components already - each suited for a particular workload not
considering others. I would hope for a simplification in that area
rather than yet another option on top. Now, I might be just unfair here
because I am not deeply familiar with Z* stuff but just looking at the
configuration space makes my head hurt.

> >> * limiting the amount of zpool users doesn't make much sense to me,
> >>   after all :)
> >
> > I am not sure I understand this part. Could you be more specific?
> 
> Well, the thought was trivial: if there is an API which provides
> abstraction for compressed objects storage, why not have several users
> of it rather than 1,5?

Because the configuration space is already too complicated and poor user
has to decide what to use somehow. I would be completely lost on what to
use now... From a first thought I would rather go with a better
comprimation but is there any risk that I would end up using much more
CPU for that or that I might be just too unlucky and my data wouldn't
compress enough to fit in?

> What we need to do is to provide a better
> documentation (I must admit I wasn't that good in doing this) on when
> to use what.

That would be certainly appreciated.

Thanks!
-- 
Michal Hocko
SUSE Labs