From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
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 18:42:50 +0900 [thread overview]
Message-ID: <akzJlY53m3XBg9Is@google.com> (raw)
In-Reply-To: <20260707093024.DPG2lvt_@linutronix.de>
On (26/07/07 11:30), Sebastian Andrzej Siewior wrote:
> > > > 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.
> >
> > So the idea was to separate lockdep maps and keep them per-device
> > because various zram devices can be on different IO paths with very
> > different locking graphs. E.g. zram0 can be a swap device with all
> > the locks that swap layer has, while zram1 can be a "normal" block
> > device mounted with ext4 with all the locks that ext4/vfs bring.
>
> Ach so index will be 0 for zram0 and 1 for zram1? In that case it is
> different from what I assumed. But you use the same key so I think it
> will be the same lock from lockdep's point of view. Like it will
> complain if you do
> zram_slot_lock(zram, 0);
> zram_slot_lock(zram, 1);
index is PAGE_SIZE granularity "block" of device that holds compressed
data. So they go from 0 to zram->disksize / PAGE_SIZE. Should I use
dedicated per device key as well?
next prev parent reply other threads:[~2026-07-07 9:42 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
2026-07-07 8:15 ` Sergey Senozhatsky
2026-07-07 9:30 ` Sebastian Andrzej Siewior
2026-07-07 9:42 ` Sergey Senozhatsky [this message]
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=akzJlY53m3XBg9Is@google.com \
--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 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.