On Thu, Jan 31, 2013 at 01:06:46PM -0600, Seth Jennings wrote: > On 01/31/2013 01:07 AM, Minchan Kim wrote: > > On Tue, Jan 29, 2013 at 03:40:23PM -0600, Seth Jennings wrote: > >> zswap is a thin compression backend for frontswap. It receives > >> pages from frontswap and attempts to store them in a compressed > >> memory pool, resulting in an effective partial memory reclaim and > >> dramatically reduced swap device I/O. > >> > >> Additionally, in most cases, pages can be retrieved from this > >> compressed store much more quickly than reading from tradition > >> swap devices resulting in faster performance for many workloads. > >> > >> This patch adds the zswap driver to mm/ > >> > >> Signed-off-by: Seth Jennings <sjenning@xxxxxxxxxxxxxxxxxx> > >> --- > >> mm/Kconfig | 15 ++ > >> mm/Makefile | 1 + > >> mm/zswap.c | 656 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 3 files changed, 672 insertions(+) > >> create mode 100644 mm/zswap.c > >> > >> diff --git a/mm/Kconfig b/mm/Kconfig > >> index 278e3ab..14b9acb 100644 > >> --- a/mm/Kconfig > >> +++ b/mm/Kconfig > >> @@ -446,3 +446,18 @@ config FRONTSWAP > >> and swap data is stored as normal on the matching swap device. > >> > >> If unsure, say Y to enable frontswap. > >> + > >> +config ZSWAP > >> + bool "In-kernel swap page compression" > >> + depends on FRONTSWAP && CRYPTO > >> + select CRYPTO_LZO > >> + select ZSMALLOC > > > > Again, I'm asking why zswap should have a dependent on CRPYTO? > > Couldn't we support it as a option? I'd like to use zswap without CRYPTO > > like zram. > > The reason we need CRYPTO is that zswap uses it to support a pluggable > compression model. zswap can use any compressor that has a crypto API > driver. zswap has _symbol dependencies_ on CRYPTO. If it isn't > selected, the build breaks. I think we can factor out compressoin part and remove dependency at compile time by Kconfig. No? Of course, if we disable CRYPTO in Kconfig, we lost pluggable model but not a problem for embedded system. Anyway, If it's a burden for you at a moment, I'm not going to insist on it. Will do it for myself. -- Kind regards, Minchan Kim _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
