linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: akpm@linux-foundation.org, yosry.ahmed@linux.dev,
	hdanton@sina.com, ryncsn@gmail.com, bigeasy@linutronix.de,
	minchan@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, senozhatsky@chromium.org
Subject: Re: [PATCH v9 14/19] zsmalloc: introduce new object mapping API
Date: Sat, 1 Mar 2025 15:22:59 +0800	[thread overview]
Message-ID: <Z8K10w-6fIpDhYc6@gondor.apana.org.au> (raw)
In-Reply-To: <20250227043618.88380-15-senozhatsky@chromium.org>

Sergey Senozhatsky <senozhatsky@chromium.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@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


  parent reply	other threads:[~2025-03-01  7:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  4:35 [PATCH v9 00/19] zsmalloc/zram: there be preemption Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 01/19] zram: sleepable entry locking Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 02/19] zram: permit preemption with active compression stream Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 03/19] zram: remove unused crypto include Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 04/19] zram: remove max_comp_streams device attr Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 05/19] zram: remove second stage of handle allocation Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 06/19] zram: no-warn about zsmalloc " Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 07/19] zram: remove writestall zram_stats member Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 08/19] zram: limit max recompress prio to num_active_comps Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 09/19] zram: filter out recomp targets based on priority Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 10/19] zram: rework recompression loop Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 11/19] zram: move post-processing target allocation Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 12/19] zsmalloc: rename pool lock Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 13/19] zsmalloc: make zspage lock preemptible Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 14/19] zsmalloc: introduce new object mapping API Sergey Senozhatsky
2025-02-27  5:48   ` Yosry Ahmed
2025-02-27  6:54     ` Sergey Senozhatsky
2025-02-27  7:09       ` Yosry Ahmed
2025-03-01  7:22   ` Herbert Xu [this message]
2025-03-03  2:42     ` Sergey Senozhatsky
2025-03-03  2:51       ` Herbert Xu
2025-02-27  4:35 ` [PATCH v9 15/19] zram: switch to new zsmalloc " Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 16/19] zram: permit reclaim in zstd custom allocator Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 17/19] zram: do not leak page on recompress_store error path Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 18/19] zram: do not leak page on writeback_store " Sergey Senozhatsky
2025-02-27  4:35 ` [PATCH v9 19/19] zram: add might_sleep to zcomp API Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8K10w-6fIpDhYc6@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ryncsn@gmail.com \
    --cc=senozhatsky@chromium.org \
    --cc=yosry.ahmed@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox