From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Hillf Danton <hdanton@sina.com>
Cc: Barry Song <21cnbao@gmail.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Brian Geffon <bgeffon@google.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v6 09/13] zram: split zcomp into separate R/W streams
Date: Fri, 23 Oct 2026 14:01:32 +0900 [thread overview]
Message-ID: <atrnvuQkeldgPqH5@google.com> (raw)
In-Reply-To: <20261022111151.960-1-hdanton@sina.com>
On (26/10/22 19:11), Hillf Danton wrote:
[..]
> What I am confused is -- why decompression needs to run faster without boosting
> compression up. Where is the compressed material?
In a typical embedded device (e.g. android) zram write is swap-out
(direct, indirect kswapd, or backgroud service swapping out idle apps),
users don't see those. zram read, on the contrary, is what users
see - because that's swap-in, read bursts when user brings back idle
app (camera app, etc.) which needs to get back to foregound quickly.
So, the read path is more important.
I tested the series against PE.
readers vs readers (no writers) 3 runs
BASE+PE IOPS 1,449k avg 3.48us sd 155.6us p99.99 26.8us max 280,820us
IOPS 1,435k avg 3.69us sd 322.9us p99.99 24.2us max 540,512us
IOPS 1,459k avg 3.46us sd 92.8us p99.99 25.5us max 172,186us
PATCHED+PE IOPS 1,457k avg 3.31us sd 15.9us p99.99 25.5us max 7,580us
IOPS 1,475k avg 3.28us sd 14.6us p99.99 24.5us max 7,327us
IOPS 1,463k avg 3.32us sd 17.2us p99.99 28.5us max 6,816us
R/W stream split makes sense for reasons that we already mentioned.
Readers don't need to be blocked on Writers - they don't compete for
the same data. And, moreover, readers don't need to be serialized at
all for stateful decompression.
writers vs readers 3 runs
BASE+PE IOPS 1,271k avg 5.57us sd 1,393us p99.99 27.5us max 1,581,800us
IOPS 1,461k avg 3.43us sd 78us p99.99 23.9us max 227,015us
IOPS 1,444k avg 3.48us sd 222us p99.99 23.9us max 592,628us
PATCHED+PE IOPS 1,457k avg 3.32us sd 18us p99.99 27.5us max 5,620us
IOPS 1,464k avg 3.31us sd 17us p99.99 24.2us max 5,621us
IOPS 1,475k avg 3.29us sd 16us p99.99 26.5us max 5,620us
And, in addition, R/W streams split saves per-CPU memory.
next prev parent reply other threads:[~2026-10-23 5:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 2:42 [PATCH v6 00/13] zram: redesign zcomp and rework backends Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 01/13] zram: prefix backends printk-s Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 02/13] zram: remove debugfs entry on init failure Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 03/13] zram: reset writeback state in zram_reset_device() Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 04/13] zram: zstd: do not allocate empty C/D-dictionaries Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 05/13] zram: lz4hc: pre-initialize dictionary stream in setup_params Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 06/13] zram: lz4: use LZ4_decompress_safe_usingDict() Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 07/13] zram: lz4hc: " Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 08/13] zram: zstd: do not use kvzalloc() for zstd allocations Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 09/13] zram: split zcomp into separate R/W streams Sergey Senozhatsky
2026-10-21 4:23 ` Hillf Danton
2026-10-21 4:56 ` Sergey Senozhatsky
2026-10-21 7:53 ` Hillf Danton
2026-10-22 0:08 ` Hillf Danton
2026-10-22 0:19 ` Barry Song
2026-10-22 11:11 ` Hillf Danton
2026-10-23 5:01 ` Sergey Senozhatsky [this message]
2026-10-22 2:06 ` Sergey Senozhatsky
2026-10-22 23:25 ` Hillf Danton
2026-10-23 3:29 ` Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 10/13] zram: introduce shared decompression streams Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 11/13] zram: allocate bounce buffer for spanning objects Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 12/13] zram: borrow idle decompression streams in exclusive mode Sergey Senozhatsky
2026-10-21 2:42 ` [PATCH v6 13/13] 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=atrnvuQkeldgPqH5@google.com \
--to=senozhatsky@chromium.org \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bgeffon@google.com \
--cc=hdanton@sina.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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®