From: Minchan Kim <minchan@kernel.org>
To: Luigi Semenzato <semenzato@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>,
Seth Jennings <sjenning@linux.vnet.ibm.com>,
Nitin Gupta <ngupta@vflare.org>,
Konrad Rzeszutek Wilk <konrad@darnok.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Pekka Enberg <penberg@cs.helsinki.fi>,
Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH v6 0/5] zram/zsmalloc promotion
Date: Thu, 15 Aug 2013 01:17:53 +0900 [thread overview]
Message-ID: <20130814161753.GB2706@gmail.com> (raw)
In-Reply-To: <CAA25o9Q1KVHEzdeXJFe9A8K9MULysq_ShWrUBZM4-h=5vmaQ8w@mail.gmail.com>
Hi Luigi,
On Wed, Aug 14, 2013 at 08:53:31AM -0700, Luigi Semenzato wrote:
> During earlier discussions of zswap there was a plan to make it work
> with zsmalloc as an option instead of zbud. Does zbud work for
AFAIR, it was not an optoin but zsmalloc was must but there were
several objections because zswap's notable feature is to dump
compressed object to real swap storage. For that, zswap needs to
store bounded objects in a zpage so that dumping could be bounded, too.
Otherwise, it could encounter OOM easily.
> compression factors better than 2:1? I have the impression (maybe
> wrong) that it does not. In our use of zram (Chrome OS) typical
Since zswap changed allocator from zsmalloc to zbud, I didn't follow
because I had no interest of low compressoin ratio allocator so
I have no idea of status of zswap at a moment but I guess it would be
still 2:1.
> overall compression ratios are between 2.5:1 and 3:1. We would hate
> to waste that memory if we switch to zswap.
If you have real swap storage, zswap might be better although I have
no number but real swap is money for embedded system and it has sudden
garbage collection on firmware side if we use eMMC or SSD so that it
could affect system latency. Morever, if we start to use real swap,
maybe we should encrypt the data and it would be severe overhead(CPU
and Power).
And what I am considering after promoting for zram feature is
asynchronous I/O and it's possible because zram is block device.
Thanks!
--
Kind regards,
Minchan Kim
--
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:[~2013-08-14 16:18 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 5:55 [PATCH v6 0/5] zram/zsmalloc promotion Minchan Kim
2013-08-14 5:55 ` [PATCH v6 1/5] zsmalloc: add Kconfig for enabling page table method Minchan Kim
2013-08-14 5:55 ` [PATCH v6 2/5] zsmalloc: add more comment Minchan Kim
2013-08-14 5:55 ` [PATCH v6 3/5] zsmalloc: move it under zram Minchan Kim
2013-08-16 22:00 ` Seth Jennings
2013-08-20 4:21 ` Minchan Kim
2013-08-14 5:55 ` [PATCH v6 4/5] mm: export unmap_kernel_range Minchan Kim
2013-08-14 5:55 ` [PATCH v6 5/5] zram: promote zram from staging Minchan Kim
2013-08-14 15:53 ` [PATCH v6 0/5] zram/zsmalloc promotion Luigi Semenzato
2013-08-14 16:17 ` Minchan Kim [this message]
2013-08-15 0:18 ` Bob Liu
2013-08-15 15:03 ` Seth Jennings
2013-08-16 2:02 ` Wanpeng Li
2013-08-16 2:02 ` Wanpeng Li
[not found] ` <520d883a.a2f6420a.6f36.0d66SMTPIN_ADDED_BROKEN@mx.google.com>
2013-08-16 4:35 ` Minchan Kim
2013-08-16 7:02 ` Alex Elsayed
2013-08-14 17:40 ` Mel Gorman
2013-08-14 18:15 ` Luigi Semenzato
2013-08-14 18:58 ` Minchan Kim
2013-08-15 17:12 ` Mel Gorman
2013-08-16 1:52 ` Bob Liu
2013-08-16 1:53 ` Bob Liu
2013-08-16 4:26 ` Minchan Kim
2013-08-16 4:55 ` Bob Liu
2013-08-16 8:33 ` Mel Gorman
2013-08-16 9:12 ` Mel Gorman
2013-08-16 9:18 ` Bob Liu
2013-08-16 12:49 ` Greg Kroah-Hartman
2013-08-16 9:12 ` Bob Liu
2013-08-19 3:18 ` Minchan Kim
2013-08-19 3:57 ` Bob Liu
2013-08-19 4:37 ` Minchan Kim
2013-08-19 5:29 ` Luigi Semenzato
2013-08-19 6:07 ` Bob Liu
2013-08-19 6:11 ` Minchan Kim
-- strict thread matches above, loose matches on Subject: below --
2013-08-14 5:51 Minchan Kim
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=20130814161753.GB2706@gmail.com \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=gregkh@linuxfoundation.org \
--cc=konrad@darnok.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=ngupta@vflare.org \
--cc=penberg@cs.helsinki.fi \
--cc=semenzato@google.com \
--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).