Re: Confusing olddefault prompt for Z3FOLD

[Michal Hocko]

On Thu 28-04-16 13:35:45, Vitaly Wool wrote:
> On Wed, Apr 27, 2016 at 2:31 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> > On Tue 26-04-16 12:08:30, Valdis Kletnieks wrote:
> >> Saw this duplicate prompt text in today's linux-next in a 'make oldconfig':
> >>
> >> Low density storage for compressed pages (ZBUD) [Y/n/m/?] y
> >> Low density storage for compressed pages (Z3FOLD) [N/m/y/?] (NEW) ?
> >>
> >> I had to read the help texts for both before I clued in that one used
> >> two compressed pages, and the other used 3.
> >>
> >> And 'make oldconfig' doesn't have a "Wait, what?" option to go back
> >> to a previous prompt....
> >>
> >> (Change Z3FOLD prompt to "New low density" or something? )
> >
> > Or even better can we only a single one rather than 2 algorithms doing
> > the similar thing? I wasn't following this closely but what is the
> > difference to have them both?
> 
> The v3 version of z3fold doesn't claim itself to be a low density storage :)
> The reasons to have them both are listed in [1] and mentioned in [2].
> 
Thanks for the pointer!

> [1] https://lkml.org/lkml/2016/4/25/526

> * 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

Does this difference actually matter for somebody to not use z3fold if
the overal savings in the compressed memory are better? I also suspect
that even small configs might not save too much because of the internal
fragmentation.

> * some system configurations might break if we removed zbud

Why would they break? Are the two incompatible? Or to be more specific
what should be the criteria to chose one over the other?

> * 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.

> * 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?

Just to clarify I am not opposing an idea of a new page compressing
algorithm. I just think that the config space in this area is way to
large and confusing. One has the scratch his head to find out what to
enable and for what reasons. The config help text didn't tell me which
is suitable for which kind of workload. All I can tell from it is that I
want 3 pages compressed rather than 2 so why bother having both of them?
-- 
Michal Hocko
SUSE Labs