lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 01 Feb 2013 09:31:09 -0600 From: Seth Jennings <sjenning@...ux.vnet.ibm.com> To: Minchan Kim <minchan@...nel.org> CC: Andrew Morton <akpm@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Nitin Gupta <ngupta@...are.org>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Dan Magenheimer <dan.magenheimer@...cle.com>, Robert Jennings <rcj@...ux.vnet.ibm.com>, Jenifer Hopper <jhopper@...ibm.com>, Mel Gorman <mgorman@...e.de>, Johannes Weiner <jweiner@...hat.com>, Rik van Riel <riel@...hat.com>, Larry Woodman <lwoodman@...hat.com>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org Subject: Re: [PATCHv4 3/7] zswap: add to mm/ On 01/31/2013 08:38 PM, Minchan Kim wrote: > 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@...ux.vnet.ibm.com> >>>> --- >>>> 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? I'm still not following. How would one "factor out" the crypto API dependency when we use it to access the compressor modules. The only thing I can think you're saying is to hack up the code with ifdefs to call the lzo code directly based on a Kconfig option. I really hope you aren't saying that though :-/ > Of course, if we disable CRYPTO in Kconfig, > we lost pluggable model but not a problem for embedded system. The pluggable model is _very_ necessary for us because we use it to access our hardware compression accelerator. We do not use lzo in that case. We use 842 (crypto/842.c and drivers/crypto/nx/nx-842.c). I'm not sure why we are misunderstanding on this. Is there a specific objection to depending the crypto API here? I understand that you are thinking about embedded systems. Does the enabling CRYPTO and CRYPTO_LZO add significant size to the kernel or something? Just trying to understand why this is a problem. Thanks, Seth > > Anyway, If it's a burden for you at a moment, I'm not going to insist on it. > Will do it for myself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists