From: Hillf Danton <hdanton@sina.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Barry Song <21cnbao@gmail.com>,
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: Sun, 25 Oct 2026 09:11:25 +0800 [thread overview]
Message-ID: <20261025011126.1100-1-hdanton@sina.com> (raw)
In-Reply-To: <20261024101401.1035-1-hdanton@sina.com>
On Sat, 24 Oct 2026 18:14:00 +0800 Hillf Danton wrote:
>On Sat, 24 Oct 2026 14:48:32 +0900 Sergey Senozhatsky wrote:
>> On (26/10/23 19:40), Hillf Danton wrote:
>> [..]
>> > > 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
>>
>> BASE+PE looked noisy, so I sat down and tested properly (also tested
>> zstd and various compression levels).
>
> Lets see the data from another pov (feel free to disagree) -- in the android
> phone/car cockpit environment, the render frequence is required above 60HZ,
> IOW a frame rendered within 16ms, so what share of the 16ms does the IOPS
> account for after this patchset, for example when an app in background is
> brought foreground?
>
I mean cpu cycles are burned to reclaim pages, given zram and swapout/in, OTOH
given whatever a GPU, slow or fast, if it would take more than 16ms to render
a frame, then there is no cure for the dilemma.
next prev parent reply other threads:[~2026-10-25 1:11 UTC|newest]
Thread overview: 32+ 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
2026-10-23 11:40 ` Hillf Danton
2026-10-24 5:48 ` Sergey Senozhatsky
2026-10-24 10:14 ` Hillf Danton
2026-10-25 1:11 ` Hillf Danton [this message]
2026-10-25 1:38 ` Sergey Senozhatsky
2026-10-25 10:54 ` Hillf Danton
2026-10-22 2:06 ` Sergey Senozhatsky
2026-10-22 23:25 ` Hillf Danton
2026-10-23 3:29 ` Sergey Senozhatsky
2026-10-23 17:05 ` Brian Geffon
2026-10-26 3:09 ` 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=20261025011126.1100-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bgeffon@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.