On 11/20/2015 2:19 PM, Herbert Xu wrote:
On Fri, Nov 20, 2015 at 03:04:47PM +0900, Joonsoo Kim wrote:
Linearization would be enough to use sg-list but it has a problem.
Linearization needs sleepable function such as vmap() and it makes
sync (de)compression in atomic context impossible. Currently, zram
did sync (de)compression in atomic context. It uses map_vm_area() which
isn't sleepable function to linearize two separate pages. This is possible
because zram already knows that maximum number of spread pages is just two
and have allocated vm area in advance. But, if we implement linearization
in general API, we can't be sure of request input size so we need
sleepable function, vmap().
And, this sleep could degrade performance.
Obviously you would only perform linearisation where it's needed.
And if you are in an atomic context, then clearly linearisation
can only be attempted using kmalloc/alloc_pages with GFP_ATOMIC.
I don't understand your concern with zram because either zram is
already feeding us linear buffers in which case linearisation is
never needed. Or it can only be used with algorithms that support
SG lists or partial updates, which we can easily mark using a flag.
Intermediate buffer size could vary greatly so it would be allocated and
Freed whenever requested. This could affect performance.
That's for the crypto user to figure out. Either they should
supply a completely linear buffer if they want to be able to
support every algorithm in an efficient manner, or they will
either have to eat the cost of linearisation or only use algorithms
that can deal with SG lists efficiently.
We have the same problem with network drivers and it's dealt with
in exactly the same way. An skb can be an SG list and will be
linearised when necessary.
I think that supporting unified API has more loss than gain.
I disagree. I have seen no valid reason so far for adding two
compression interfaces.
Cheers,
Thanks Herbert.
If we assume the sg-list can be linearized - no "holes" in the sg-list,
all chunks in middle of the list are of PAGE_SIZE, it seems ok to
support sg-list in the s/w implementation, linearize the sg-list and
compress it as one chunk.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
