RE: [PATCH V2 2/3] drivers/staging: zcache: host services and PAMservices

[Dan Magenheimer]

> From: Minchan Kim [mailto:minchan.kim@xxxxxxxxx]

> 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
non-technical:

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

Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/