From: Ric Mason <ric.masonn@gmail.com>
To: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Seth Jennings <sjenning@linux.vnet.ibm.com>,
Konrad Rzeszutek Wilk <konrad@darnok.org>,
Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Fengguang Wu <fengguang.wu@intel.com>,
Bob Liu <bob.liu@oracle.com>
Subject: Re: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently
Date: Sun, 07 Apr 2013 17:12:47 +0800 [thread overview]
Message-ID: <5161388F.7060905@gmail.com> (raw)
In-Reply-To: <5161367e.c60c320a.5936.ffff86a9SMTPIN_ADDED_BROKEN@mx.google.com>
cc Bob
On 04/07/2013 05:03 PM, Wanpeng Li wrote:
> On Wed, Apr 03, 2013 at 06:16:20PM +0800, Wanpeng Li wrote:
>> Changelog:
>> v5 -> v6:
>> * shove variables in debug.c and in debug.h just have an extern, spotted by Konrad
>> * update patch description, spotted by Konrad
>> v4 -> v5:
>> * fix compile error, reported by Fengguang, Geert
>> * add check for !is_ephemeral(pool), spotted by Bob
>> v3 -> v4:
>> * handle duplication in page_is_zero_filled, spotted by Bob
>> * fix zcache writeback in dubugfs
>> * fix pers_pageframes|_max isn't exported in debugfs
>> * fix static variable defined in debug.h but used in multiple C files
>> * rebase on Greg's staging-next
>> v2 -> v3:
>> * increment/decrement zcache_[eph|pers]_zpages for zero-filled pages, spotted by Dan
>> * replace "zero" or "zero page" by "zero_filled_page", spotted by Dan
>> v1 -> v2:
>> * avoid changing tmem.[ch] entirely, spotted by Dan.
>> * don't accumulate [eph|pers]pageframe and [eph|pers]zpages for
>> zero-filled pages, spotted by Dan
>> * cleanup TODO list
>> * add Dan Acked-by.
>>
> Hi Dan,
>
> Some issues against Ramster:
>
> - Ramster who takes advantage of zcache also should support zero-filled
> pages more efficiently, correct? It doesn't handle zero-filled pages well
> currently.
> - Ramster DebugFS counters are exported in /sys/kernel/mm/, but zcache/frontswap/cleancache
> all are exported in /sys/kernel/debug/, should we unify them?
> - If ramster also should move DebugFS counters to a single file like
> zcache do?
>
> If you confirm these issues are make sense to fix, I will start coding. ;-)
>
> Regards,
> Wanpeng Li
>
>> Motivation:
>>
>> - Seth Jennings points out compress zero-filled pages with LZO(a lossless
>> data compression algorithm) will waste memory and result in fragmentation.
>> https://lkml.org/lkml/2012/8/14/347
>> - Dan Magenheimer add "Support zero-filled pages more efficiently" feature
>> in zcache TODO list https://lkml.org/lkml/2013/2/13/503
>>
>> Design:
>>
>> - For store page, capture zero-filled pages(evicted clean page cache pages and
>> swap pages), but don't compress them, set pampd which store zpage address to
>> 0x2(since 0x0 and 0x1 has already been ocuppied) to mark special zero-filled
>> case and take advantage of tmem infrastructure to transform handle-tuple(pool
>> id, object id, and an index) to a pampd. Twice compress zero-filled pages will
>> contribute to one zcache_[eph|pers]_pageframes count accumulated.
>> - For load page, traverse tmem hierachical to transform handle-tuple to pampd
>> and identify zero-filled case by pampd equal to 0x2 when filesystem reads
>> file pages or a page needs to be swapped in, then refill the page to zero
>> and return.
>>
>> Test:
>>
>> dd if=/dev/zero of=zerofile bs=1MB count=500
>> vmtouch -t zerofile
>> vmtouch -e zerofile
>>
>> formula:
>> - fragmentation level = (zcache_[eph|pers]_pageframes * PAGE_SIZE - zcache_[eph|pers]_zbytes)
>> * 100 / (zcache_[eph|pers]_pageframes * PAGE_SIZE)
>> - memory zcache occupy = zcache_[eph|pers]_zbytes
>>
>> Result:
>>
>> without zero-filled awareness:
>> - fragmentation level: 98%
>> - memory zcache occupy: 238MB
>> with zero-filled awareness:
>> - fragmentation level: 0%
>> - memory zcache occupy: 0MB
>>
>> Wanpeng Li (3):
>> staging: zcache: fix static variables defined in debug.h but used in
>> mutiple C files
>> staging: zcache: introduce zero-filled page stat count
>> staging: zcache: clean TODO list
>>
>> drivers/staging/zcache/TODO | 3 +-
>> drivers/staging/zcache/debug.c | 35 +++++++++++++++
>> drivers/staging/zcache/debug.h | 79 ++++++++++++++++++++-------------
>> drivers/staging/zcache/zcache-main.c | 4 ++
>> 4 files changed, 88 insertions(+), 33 deletions(-)
>>
>> --
>> 1.7.5.4
> --
> 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>
--
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>
prev parent reply other threads:[~2013-04-07 9:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 10:16 [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently Wanpeng Li
2013-04-03 10:16 ` [PATCH v6 1/3] staging: zcache: fix static variables defined in debug.h but used in mutiple C files Wanpeng Li
2013-04-03 20:13 ` Konrad Rzeszutek Wilk
2013-04-03 10:16 ` [PATCH v6 2/3] staging: zcache: introduce zero-filled page stat count Wanpeng Li
2013-04-03 20:12 ` Konrad Rzeszutek Wilk
2013-04-03 10:16 ` [PATCH v2 3/3] staging: zcache: clean TODO list Wanpeng Li
2013-04-07 9:03 ` [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently Wanpeng Li
2013-04-07 9:03 ` Wanpeng Li
2013-04-07 17:51 ` Dan Magenheimer
2013-04-07 17:59 ` Dan Magenheimer
2013-04-08 0:27 ` Wanpeng Li
2013-04-08 0:27 ` Wanpeng Li
2013-04-08 12:09 ` Wanpeng Li
2013-04-08 12:09 ` Wanpeng Li
2013-04-10 0:38 ` Wanpeng Li
2013-04-10 0:38 ` Wanpeng Li
[not found] ` <5161367e.c60c320a.5936.ffff86a9SMTPIN_ADDED_BROKEN@mx.google.com>
2013-04-07 9:12 ` Ric Mason [this message]
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=5161388F.7060905@gmail.com \
--to=ric.masonn@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bob.liu@oracle.com \
--cc=dan.magenheimer@oracle.com \
--cc=fengguang.wu@intel.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=konrad@darnok.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwanp@linux.vnet.ibm.com \
--cc=minchan@kernel.org \
--cc=sjenning@linux.vnet.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).