From: Brian Geffon <bgeffon@google.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>,
Richard Chang <richardycc@google.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 07/10] zram: zstd: do not use kvzalloc() for zstd allocations
Date: Tue, 6 Oct 2026 15:31:11 +0900 [thread overview]
Message-ID: <CADyq12wsysqxEy_7wms1TyHVXOvpmS88WoO2_N3_Cgnr9vF9Zw@mail.gmail.com> (raw)
In-Reply-To: <20261005122036.718976-8-senozhatsky@chromium.org>
On Mon, Oct 5, 2026 at 9:21 PM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> When a dictionary is configured, zstd allocates all of its memory (C/D
> dictionaries, compression and decompression contexts and compression
> workspaces) via zstd_custom_alloc(). zstd_custom_alloc() uses
> kvzalloc(), which falls back to vmalloc() only when kmalloc() fails,
> and kmalloc() rounds such sizes up to a power-of-two number of pages.
>
> For example, on x86_64 with a 110K dictionary, switching from
> kvzalloc() to __vmalloc() reduces allocations from:
> - CDict (level 3): 512 KB -> 400 KB
> - CDict (levels 12+): 2048 KB -> 1552 KB
> - DCtx (per-CPU): 128 KB -> 96 KB
> - CCtx workspace (level 3): 128 KB -> 84 KB (per-CPU)
> - CCtx workspace (level 14+): 1024 KB -> 764 KB (per-CPU)
>
> Use __vmalloc() for allocations larger than PAGE_SIZE (and kzalloc()
> for smaller ones), which is also how zram allocates zstd workspaces
> when no dictionary is configured. zstd_custom_free() already uses
> kvfree(), which handles both.
>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Acked-by: Brian Geffon <bgeffon@google.com>
> ---
> drivers/block/zram/backend_zstd.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/zram/backend_zstd.c b/drivers/block/zram/backend_zstd.c
> index b367049f131d..7a8b5ff186f2 100644
> --- a/drivers/block/zram/backend_zstd.c
> +++ b/drivers/block/zram/backend_zstd.c
> @@ -26,10 +26,17 @@ struct zstd_params {
> /*
> * For C/D dictionaries we need to provide zstd with zstd_custom_mem,
> * which zstd uses internally to allocate/free memory when needed.
> + *
> + * zstd allocations (C/D dictionaries and contexts) are large and
> + * long-lived. Don't use kvzalloc() for them: when enough physically
> + * contiguous memory is available it serves them from kmalloc(), which
> + * rounds them up to a power-of-two number of pages.
> */
> static void *zstd_custom_alloc(void *opaque, size_t size)
> {
> - return kvzalloc(size, GFP_NOIO | __GFP_NOWARN);
> + if (size <= PAGE_SIZE)
> + return kzalloc(size, GFP_NOIO | __GFP_NOWARN);
> + return __vmalloc(size, GFP_NOIO | __GFP_NOWARN | __GFP_ZERO);
> }
>
> static void zstd_custom_free(void *opaque, void *address)
> --
> 2.56.0.rc1.315.gc6ed9934b7-goog
>
next prev parent reply other threads:[~2026-10-06 6:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 12:20 [PATCH 00/10] zram: redesign zcomp and rework backends Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 01/10] zram: prefix backends printk-s Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 02/10] zram: remove debugfs entry on init failure Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 03/10] zram: zstd: do not allocate empty C/D-dictionaries Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 04/10] zram: lz4hc: pre-initialize dictionary stream in setup_params Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 05/10] zram: lz4: use LZ4_decompress_safe_usingDict() Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 06/10] zram: lz4hc: " Sergey Senozhatsky
2026-10-06 6:22 ` Brian Geffon
2026-10-05 12:20 ` [PATCH 07/10] zram: zstd: do not use kvzalloc() for zstd allocations Sergey Senozhatsky
2026-10-06 6:31 ` Brian Geffon [this message]
2026-10-05 12:20 ` [PATCH 08/10] zram: reset writeback state in zram_reset_device() Sergey Senozhatsky
2026-10-06 6:11 ` Brian Geffon
2026-10-05 12:20 ` [PATCH 09/10] zram: split zcomp into separate R/W streams Sergey Senozhatsky
2026-10-05 12:20 ` [PATCH 10/10] zram: use a singleton compression context for recompression 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=CADyq12wsysqxEy_7wms1TyHVXOvpmS88WoO2_N3_Cgnr9vF9Zw@mail.gmail.com \
--to=bgeffon@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=richardycc@google.com \
--cc=senozhatsky@chromium.org \
/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
all inboxes | Powered by JetHome®