From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yosry Ahmed <yosry.ahmed@linux.dev>,
Hillf Danton <hdanton@sina.com>, Kairui Song <ryncsn@gmail.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: [PATCH v10 00/19] zsmalloc/zram: there be preemption
Date: Mon, 3 Mar 2025 11:03:09 +0900 [thread overview]
Message-ID: <20250303022425.285971-1-senozhatsky@chromium.org> (raw)
Currently zram runs compression and decompression in non-preemptible
sections, e.g.
zcomp_stream_get() // grabs CPU local lock
zcomp_compress()
or
zram_slot_lock() // grabs entry spin-lock
zcomp_stream_get() // grabs CPU local lock
zs_map_object() // grabs rwlock and CPU local lock
zcomp_decompress()
Potentially a little troublesome for a number of reasons.
For instance, this makes it impossible to use async compression
algorithms or/and H/W compression algorithms, which can wait for OP
completion or resource availability. This also restricts what
compression algorithms can do internally, for example, zstd can
allocate internal state memory for C/D dictionaries:
do_fsync()
do_writepages()
zram_bio_write()
zram_write_page() // become non-preemptible
zcomp_compress()
zstd_compress()
ZSTD_compress_usingCDict()
ZSTD_compressBegin_usingCDict_internal()
ZSTD_resetCCtx_usingCDict()
ZSTD_resetCCtx_internal()
zstd_custom_alloc() // memory allocation
Not to mention that the system can be configured to maximize
compression ratio at a cost of CPU/HW time (e.g. lz4hc or deflate
with very high compression level) so zram can stay in non-preemptible
section (even under spin-lock or/and rwlock) for an extended period
of time. Aside from compression algorithms, this also restricts what
zram can do. One particular example is zram_write_page() zsmalloc
handle allocation, which has an optimistic allocation (disallowing
direct reclaim) and a pessimistic fallback path, which then forces
zram to compress the page one more time.
This series changes zram to not directly impose atomicity restrictions
on compression algorithms (and on itself), which makes zram write()
fully preemptible; zram read(), sadly, is not always preemptible yet.
There are still indirect atomicity restrictions imposed by zsmalloc().
One notable example is object mapping API, which returns with:
a) local CPU lock held
b) zspage rwlock held
First, zsmalloc's zspage lock is converted from rwlock to a special
type of RW-lookalike look with some extra guarantees/features. Second,
a new handle mapping is introduced which doesn't use per-CPU buffers
(and hence no local CPU lock), does fewer memcpy() calls, but requires
users to provide a pointer to temp buffer for object copy-in (when
needed). Third, zram is converted to the new zsmalloc mapping API
and thus zram read() becomes preemptible.
v9 -> v10
- moved to statically allocated lockdep lock classes in zram and
zsmalloc (Sebastian)
- dropped lock_contended() because we only can call it under
lock_acquire() and thta's not the case for zram and zsmalloc trylock
Sergey Senozhatsky (19):
zram: sleepable entry locking
zram: permit preemption with active compression stream
zram: remove unused crypto include
zram: remove max_comp_streams device attr
zram: remove second stage of handle allocation
zram: add GFP_NOWARN to incompressible zsmalloc handle allocation
zram: remove writestall zram_stats member
zram: limit max recompress prio to num_active_comps
zram: filter out recomp targets based on priority
zram: rework recompression loop
zram: move post-processing target allocation
zsmalloc: rename pool lock
zsmalloc: sleepable zspage reader-lock
zsmalloc: introduce new object mapping API
zram: switch to new zsmalloc object mapping API
zram: permit reclaim in zstd custom allocator
zram: do not leak page on recompress_store error path
zram: do not leak page on writeback_store error path
zram: add might_sleep to zcomp API
Documentation/ABI/testing/sysfs-block-zram | 8 -
Documentation/admin-guide/blockdev/zram.rst | 36 +--
drivers/block/zram/backend_zstd.c | 11 +-
drivers/block/zram/zcomp.c | 48 ++-
drivers/block/zram/zcomp.h | 8 +-
drivers/block/zram/zram_drv.c | 330 +++++++++-----------
drivers/block/zram/zram_drv.h | 17 +-
include/linux/zsmalloc.h | 8 +
mm/zsmalloc.c | 329 ++++++++++++++-----
9 files changed, 478 insertions(+), 317 deletions(-)
--
2.48.1.711.g2feabab25a-goog
next reply other threads:[~2025-03-03 2:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 2:03 Sergey Senozhatsky [this message]
2025-03-03 2:03 ` [PATCH v10 01/19] zram: sleepable entry locking Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 02/19] zram: permit preemption with active compression stream Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 03/19] zram: remove unused crypto include Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 04/19] zram: remove max_comp_streams device attr Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 05/19] zram: remove second stage of handle allocation Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 06/19] zram: add GFP_NOWARN to incompressible zsmalloc " Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 07/19] zram: remove writestall zram_stats member Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 08/19] zram: limit max recompress prio to num_active_comps Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 09/19] zram: filter out recomp targets based on priority Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 10/19] zram: rework recompression loop Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 11/19] zram: move post-processing target allocation Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 12/19] zsmalloc: rename pool lock Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 13/19] zsmalloc: sleepable zspage reader-lock Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 14/19] zsmalloc: introduce new object mapping API Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 15/19] zram: switch to new zsmalloc " Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 16/19] zram: permit reclaim in zstd custom allocator Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 17/19] zram: do not leak page on recompress_store error path Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 18/19] zram: do not leak page on writeback_store " Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 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=20250303022425.285971-1-senozhatsky@chromium.org \
--to=senozhatsky@chromium.org \
--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=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