On Tue, Jun 28, 2016 at 08:41:42AM +0100, Giovanni Cabiddu wrote:
>
> Are you suggesting a different cache of scratch buffers for every
> algorithm implementation or a shared cache shared across all legacy
> scomp algorithms?
One that's shared for every scomp algorithm.
> Would it be ok 128K inst
On Fri, Jun 24, 2016 at 05:26:43PM +0800, Herbert Xu wrote:
> Hmm, I guess we can still keep scomp and use vmalloc until someone
> spends the effort and optimises each algorithm to make them use acomp
> directly.
Ok.
> So I'd still like to move the allocation down into the algorithm.
> That way IP
On Fri, Jun 24, 2016 at 09:37:28AM +0100, Giovanni Cabiddu wrote:
>
> I'll remove scomp and refit the software algos to plug into acomp
> directly.
> Would it be admissible if software algos implementations will vmalloc
> the source and the destination buffers for linearizing the scatter gather
> l
On Thu, Jun 23, 2016 at 06:50:34PM +0800, Herbert Xu wrote:
> No that's not the problem. The problem is that you can't kmalloc
> 64K of memory. kmalloc requires physically contiguous memory and
> you cannot rely on having 64K of contiguous memory.
It is clear now. Thanks.
> > > This totally brea
On Wed, Jun 22, 2016 at 04:53:50PM +0100, Giovanni Cabiddu wrote:
> On Mon, Jun 13, 2016 at 04:56:12PM +0800, Herbert Xu wrote:
> > The backup path is also very unlikely to work because we'll be
> > hitting this with 64K sizes and this just won't work with a 4K
> > page size.
> Is scatterwalk_map_a
On Mon, Jun 13, 2016 at 04:56:12PM +0800, Herbert Xu wrote:
> The backup path is also very unlikely to work because we'll be
> hitting this with 64K sizes and this just won't work with a 4K
> page size.
Is scatterwalk_map_and_copy broken?
> So up until now we've getting around this 64K issue with
On Wed, Jun 08, 2016 at 09:16:52AM +0100, Giovanni Cabiddu wrote:
>
> +static void *scomp_map(struct scatterlist *sg, unsigned int len,
> +gfp_t gfp_flags)
> +{
> + void *buf;
> +
> + if (sg_is_last(sg))
> + return kmap_atomic(sg_page(sg)) + sg->offset;
This
Add a synchronous back-end (scomp) to acomp. This allows to easily expose
the already present compression algorithms in LKCF via acomp
Signed-off-by: Giovanni Cabiddu
---
crypto/Makefile |1 +
crypto/acompress.c | 49 +++-
crypto/scompress.c
