LKML Archive on
help / color / mirror / Atom feed
From: Dan Magenheimer <>
To: Minchan Kim <>
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:39:37 -0800 (PST)	[thread overview]
Message-ID: <5c529b08-cf36-43c7-b368-f3f602faf358@default> (raw)
In-Reply-To: <>

> From: Minchan Kim []

> As I read your comment, I can't find the benefit of zram compared to
> frontswap.

Well, I am biased, but I agree that frontswap is a better technical
solution than zram. ;-)  But "dynamic-ity" is very important to
me and may be less important to others.

I thought of these other differences, both technical and

- Zram is minimally invasive to the swap subsystem, requiring only
  one hook which is already upstream (though see below) and is
  apparently already used by some Linux users.  Frontswap is somewhat
  more invasive and, UNTIL zcache-was-kztmem was posted a few weeks
  ago, had no non-Xen users (though some distros are already shipping
  the hooks in their kernels because Xen supports it); as a result,
  frontswap has gotten almost no review by kernel swap subsystem
  experts who I'm guessing weren't interested in anything that
  required Xen to use... hopefully that barrier is now resolved
  (but bottom line is frontswap is not yet upstream).

- Zram has one-byte of overhead per page in every explicitly configured
  zram swap, the same as any real swap device.  Frontswap has one-BIT
  of overhead per page for every configured (real) swap device.

- Frontswap requires several hooks scattered through the swap subsystem:
  a) init, put, get, flush, and destroy
  b) a bit-per-page map to record whether a swapped page is in
     frontswap or on the real device
  c) a "partial swapoff" to suck stale pages out of frontswap
  Zram's one flush hook is upstream, though IMHO to be fully functional
  in the real world, it needs some form of (c) also.


  reply	other threads:[~2011-02-09 16:41 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
2011-02-09 16:39       ` Dan Magenheimer [this message]
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=5c529b08-cf36-43c7-b368-f3f602faf358@default \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --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).