From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Yosry Ahmed <yosry.ahmed@linux.dev>,
Hillf Danton <hdanton@sina.com>, Kairui Song <ryncsn@gmail.com>,
Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 01/19] zram: sleepable entry locking
Date: Tue, 7 Jul 2026 08:40:30 +0200 [thread overview]
Message-ID: <20260707064030.D843llKh@linutronix.de> (raw)
In-Reply-To: <20250303022425.285971-2-senozhatsky@chromium.org>
On 2025-03-03 11:03:10 [+0900], Sergey Senozhatsky wrote:
…
> Having a per-entry mutex (or, for instance, a rw-semaphore)
> significantly increases sizeof() of each entry and hence the
> meta table. Therefore entry locking returns back to bit
> locking, as before, however, this time also preempt-rt friendly,
> because if waits-on-bit instead of spinning-on-bit. Lock owners
of ?
> are also now permitted to schedule, which is a first step on the
> path of making zram non-atomic.
>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
…
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -58,19 +58,56 @@ static void zram_free_page(struct zram *zram, size_t index);
> static int zram_read_from_zspool(struct zram *zram, struct page *page,
> u32 index);
>
> -static int zram_slot_trylock(struct zram *zram, u32 index)
> +#define slot_dep_map(zram, index) (&(zram)->table[(index)].dep_map)
> +
> +static void zram_slot_lock_init(struct zram *zram, u32 index)
> +{
> + static struct lock_class_key __key;
> +
> + lockdep_init_map(slot_dep_map(zram, index), "zram->table[index].lock",
> + &__key, 0);
> +}
…
> +static __must_check bool zram_slot_trylock(struct zram *zram, u32 index)
> {
> - return spin_trylock(&zram->table[index].lock);
> + unsigned long *lock = &zram->table[index].flags;
> +
> + if (!test_and_set_bit_lock(ZRAM_ENTRY_LOCK, lock)) {
> + mutex_acquire(slot_dep_map(zram, index), 0, 1, _RET_IP_);
> + lock_acquired(slot_dep_map(zram, index), _RET_IP_);
> + return true;
> + }
> +
> + return false;
> }
>
> static void zram_slot_lock(struct zram *zram, u32 index)
> {
> - spin_lock(&zram->table[index].lock);
> + unsigned long *lock = &zram->table[index].flags;
> +
> + mutex_acquire(slot_dep_map(zram, index), 0, 0, _RET_IP_);
> + wait_on_bit_lock(lock, ZRAM_ENTRY_LOCK, TASK_UNINTERRUPTIBLE);
> + lock_acquired(slot_dep_map(zram, index), _RET_IP_);
> }
Looking at this, is there a special need to have a lockdep map per
table? Wouldn't it be enough to have one per zram? Logically you use the
same __key so I don't think it makes much of a difference but you could
lower the memory usage a bit by having less of those structs per zram.
Sebastian
next prev parent reply other threads:[~2026-07-07 6:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 2:03 [PATCH v10 00/19] zsmalloc/zram: there be preemption Sergey Senozhatsky
2025-03-03 2:03 ` [PATCH v10 01/19] zram: sleepable entry locking Sergey Senozhatsky
2026-07-07 6:40 ` Sebastian Andrzej Siewior [this message]
2026-07-07 8:15 ` Sergey Senozhatsky
2026-07-07 9:30 ` Sebastian Andrzej Siewior
2026-07-07 9:42 ` Sergey Senozhatsky
2026-07-07 10:02 ` Sebastian Andrzej Siewior
2026-07-07 10:55 ` 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
2026-07-07 7:25 ` Sebastian Andrzej Siewior
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=20260707064030.D843llKh@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--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 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.