LKML Archive on
help / color / mirror / Atom feed
From: Minchan Kim <>
To: Dan Magenheimer <>
Cc:, Chris Mason <>,,,,,,,,
	Kurt Hackel <>,,,
	Konrad Wilk <>,,,,,,,,
Subject: Re: [PATCH V2 2/3] drivers/staging: zcache: host services and PAM services
Date: Wed, 9 Feb 2011 08:56:07 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <0d1aa13e-be1f-4e21-adf2-f0162c67ede3@default>

On Wed, Feb 9, 2011 at 8:27 AM, Dan Magenheimer
<> wrote:
> Hi Minchan --
>> First of all, thanks for endless effort.
> Sometimes it does seem endless ;-)
>> I didn't look at code entirely but it seems this series includes
>> frontswap.
> The "new zcache" optionally depends on frontswap, but frontswap is
> a separate patchset.  If the frontswap patchset is present
> and configured, zcache will use it to dynamically compress swap pages.
> If frontswap is not present or not configured, zcache will only
> use cleancache to dynamically compress clean page cache pages.
> For best results, both frontswap and cleancache should be enabled.
> (and see the link in PATCH V2 0/3 for a monolithic patch against
> 2.6.37 that enabled both).
>> Finally frontswap is to replace zram?
> Nitin and I have agreed that, for now, both frontswap and zram
> should continue to exist.  They have similar functionality but
> different use models.  Over time we will see if they can be merged.
> Nitin and I agreed offlist that the following summarizes the
> differences between zram and frontswap:
> ===========
> Zram uses an asynchronous model (e.g. uses the block I/O subsystem)
> and requires a device to be explicitly created.  When used for
> swap, mkswap creates a fixed-size swap device (usually with higher
> priority than any disk-based swap device) and zram is filled
> until it is full, at which point other lower-priority (disk-based)
> swap devices are then used.  So zram is well-suited for a fixed-
> size-RAM machine with a known workload where an administrator
> can pre-configure a zram device to improve RAM efficiency during
> peak memory load.
> Frontswap uses a synchronous model, circumventing the block I/O
> subsystem.  The frontswap "device" is completely dynamic in size,
> e.g. frontswap is queried for every individual page-to-be-swapped
> and, if rejected, the page is swapped to the "real" swap device.
> So frontswap is well-suited for highly dynamic conditions where
> workload is unpredictable and/or RAM size may "vary" due to
> circumstances not entirely within the kernel's control.
> ==========
> Does that make sense?

Thanks for the quick reply.
As I read your comment, I can't find the benefit of zram compared to frontswap.

1. asynchronous model
2. usability
3. adaptive dynamic ram size

If I consider your statement, with 2, 3, zram isn't better than
fronswap, I think.
1 on zram may be good than frontswap but I doubt how much we have a
big benefit on async operation in ramdisk model.

If we have a big overhead of block stuff in such a model, couldn't we
remove the overhead generally?

What I can think of benefit is that zram export interface to block
device so someone can use compressed block device.
Block device interface exporting is enough to live zram in there?

Maybe I miss something of zram's benefits.
At least, I can't convince why zram and frontswap should coexist.
AFAIK, Nitin and you discussed it many times long time ago but I
didn't follow up it.  Sorry if I am missing something.


Kind regards,
Minchan Kim

  reply	other threads:[~2011-02-08 23:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07  3:26 Dan Magenheimer
2011-02-08 22:48 ` Minchan Kim
2011-02-08 23:27   ` Dan Magenheimer
2011-02-08 23:56     ` Minchan Kim [this message]
2011-02-09 16:39       ` Dan Magenheimer
2011-02-09 17:36         ` Nitin Gupta
2011-02-09 23:46           ` Minchan Kim
2011-02-10  1:17             ` Nitin Gupta
2011-02-09 23:57         ` Minchan Kim
2011-02-09 23:58           ` Minchan Kim
2011-02-15 16:53 ` Konrad Rzeszutek Wilk
2011-02-15 17:25   ` Greg KH
2011-02-15 18:18     ` Konrad Rzeszutek Wilk

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH V2 2/3] drivers/staging: zcache: host services and PAM services' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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