lkml.org 
[lkml]   [2014]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 2/3] zram: introduce zram compressor operations struct
On Mon, Jan 20, 2014 at 01:03:48PM +0300, Sergey Senozhatsky wrote:
> On (01/20/14 14:12), Minchan Kim wrote:
> > Hello Sergey,
> >
> > I reviewed this patchset and I suggest somethings.
> > Please have a look and feedback to me. :)
> >
> > 1. Let's define new file zram_comp.c
> > 2. zram_comp includes following field
> > .create
> > .compress
> > .decompress.
> > .destroy
> > .name
> >
>
> alternatively, we can use crypto api, the same way as zswap does (that
> will require handling of cpu hotplug).
>
> -ss

I really doubt what's the benefit from crypto API for zram.
It's maybe since I'm not familiar with it so I should ask a silly
question.

1. What's the runtime overhead for using such frontend?

As you know, zram is in-memory block device so I don't want to
add unnecessary overhead to optimize.

2. What's the memory footprint for using such frontend?

As you know, zram is very popular for small-memory embedded device
so I don't want to consume more runtime memory and static memory
due to CONFIG_CRYPTO friend.

3. Is it a flexible to alloc/handle multiple compressor buffer for
the our purpose? zswap and zcache have been used it with per-cpu
buffer but it would a problem for write scalabitliy if we uses zlib
which takes long time to compress.
When I read code, maybe we can allocate multiple buffers through
cryptop_alloc_compo several time but it would cause 1) and 2) problem
again.

So, what's the attractive point for using crypto?
One of thing I could imagine is that it could make zram H/W compressor
but I don't have heard about it so if we don't have any special reason,
I'd like to go with raw compressor so we can get a *base* number. Then,
if we really need crypto API, we can change it easily and benchmark.
Finally, we could get a comparision number in future and it would make
the decision easily.

Thanks.

--
Kind regards,
Minchan Kim


\
 
 \ /
  Last update: 2014-01-21 01:21    [W:0.146 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site