From: Vitaly Wool <vitalywool@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Dan Streetman <ddstreet@ieee.org>
Subject: Re: [PATH] z3fold: extend compaction function
Date: Thu, 3 Nov 2016 22:35:01 +0100 [thread overview]
Message-ID: <CAMJBoFNRs3HqToqFaoxigD6aHzDHjWkpOQ+mK0HiodgFdwh+kQ@mail.gmail.com> (raw)
In-Reply-To: <20161103141607.855925f33be627dea9731eb3@linux-foundation.org>
On Thu, Nov 3, 2016 at 10:16 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 3 Nov 2016 22:04:28 +0100 Vitaly Wool <vitalywool@gmail.com> wrote:
>
>> z3fold_compact_page() currently only handles the situation when
>> there's a single middle chunk within the z3fold page. However it
>> may be worth it to move middle chunk closer to either first or
>> last chunk, whichever is there, if the gap between them is big
>> enough.
>
> "may be worth it" is vague. Does the patch improve the driver or does
> it not? If it *does* improve the driver then in what way? *Why* is is
> "worth it"?
Yep, I must admit I wasn't clear enough here. Basically compression
ratio wise, it always makes sense to move middle chunk as close as
possible to another in-page z3fold object, because then the third
object can use all the remaining space. However, moving big object
just by one chunk will hurt performance without gaining much
compression ratio wise. So the gap between the middle object and the
edge object should be big enough to justify the move.
So,
this patch improves compression ratio because in-page compaction
becomes more comprehensive;
this patch (which came as a surprise) also increases performance in
fio randrw tests (I am not 100% sure why, but probably due to less
actual page allocations on hot path due to denser in-page allocation).
~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-11-03 21:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 21:04 Vitaly Wool
2016-11-03 21:16 ` Andrew Morton
2016-11-03 21:35 ` Vitaly Wool [this message]
2016-11-25 14:43 ` Dan Streetman
2016-11-25 21:17 ` Dan Streetman
2016-11-26 9:09 ` Vitaly Wool
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=CAMJBoFNRs3HqToqFaoxigD6aHzDHjWkpOQ+mK0HiodgFdwh+kQ@mail.gmail.com \
--to=vitalywool@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ddstreet@ieee.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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