On 02/01/2013 09:31 AM, Seth Jennings wrote:
> 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 <sjenn...@linux.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 :-/
Looking into this more, I found out that INET also selects CRYPTO, so
unless the kernel is not doing networking, CRYPTO will be enabled
anyway. EXT4 also selects it.
>
>> 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?
If size is the concern, I did a quick size diff between a vmlinux with
and without CRYPTO:
text data bss dec
CRYPTO=n 4747622 602704 7774208 13124534
CRYPTO=y 4755437 602960 7774208 13132605
diff 7815 256 0 8071
Bottom line is CRYPTO adds about 8k to vmlinux.
Thanks,
Seth
>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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
