> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href