From: Vitaly Wool <vitalywool@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: Confusing olddefault prompt for Z3FOLD
Date: Thu, 28 Apr 2016 21:40:48 +0200 [thread overview]
Message-ID: <CAMJBoFM3HYpfPRD2di6=QF_Ebo1fOmNCLPWzXF2RgWKB4cB6GA@mail.gmail.com> (raw)
In-Reply-To: <20160428115858.GE31489@dhcp22.suse.cz>
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:
>> On Wed, Apr 27, 2016 at 2:31 PM, Michal Hocko <mhocko@kernel.org> 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
I get significantly larger code on an ARM64 machine...
> 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.
Probably not, but I'm not the one to ask here. If I didn't want to
make something more memory efficient I wouldn't start on z3fold :)
>> * 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.
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.
>> * 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? 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.
Thanks,
Vitaly
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-04-28 19:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 16:08 Valdis Kletnieks
2016-04-27 12:31 ` Michal Hocko
2016-04-28 11:35 ` Vitaly Wool
2016-04-28 11:58 ` Michal Hocko
2016-04-28 19:40 ` Vitaly Wool [this message]
2016-04-29 12:17 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMJBoFM3HYpfPRD2di6=QF_Ebo1fOmNCLPWzXF2RgWKB4cB6GA@mail.gmail.com' \
--to=vitalywool@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox