[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8K10w-6fIpDhYc6@gondor.apana.org.au>
Date: Sat, 1 Mar 2025 15:22:59 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: akpm@...ux-foundation.org, yosry.ahmed@...ux.dev, hdanton@...a.com,
ryncsn@...il.com, bigeasy@...utronix.de, minchan@...nel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
senozhatsky@...omium.org
Subject: Re: [PATCH v9 14/19] zsmalloc: introduce new object mapping API
Sergey Senozhatsky <senozhatsky@...omium.org> wrote:
>
> New API splits functions by access mode:
> - zs_obj_read_begin(handle, local_copy)
> Returns a pointer to handle memory. For objects that span two
> physical pages a local_copy buffer is used to store object's
> data before the address is returned to the caller. Otherwise
> the object's page is kmap_local mapped directly.
I presume this buffer is always given to the compression algorithm
to decompress? In that case there should be no need to linearise
them at all.
Just return a two-entry SG list, and give it to the Crypto API
to deal with. Both software and hardware algorithms can handle
non-linear input. Yes software decompression is currently
linearising all input with a copy, but that is no different
to the copy that you're making in zsmalloc.
So please change this API to create an SG list instead of copying.
That way we can then optimise the software decompression to read
non-linear input directly and skip the copying altogether.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists