lkml.org 
[lkml]   [2016]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Confusing olddefault prompt for Z3FOLD
On Thu 28-04-16 21:40:48, Vitaly Wool wrote:
> On Thu, Apr 28, 2016 at 1:58 PM, Michal Hocko <mhocko@kernel.org> 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

\
 
 \ /
  Last update: 2016-04-29 14:41    [W:0.053 / U:2.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site