All of lore.kernel.org
 help / color / mirror / Atom feed
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 12:02:41 +0200	[thread overview]
Message-ID: <20260707100241.zaM2yrF5@linutronix.de> (raw)
In-Reply-To: <akzJlY53m3XBg9Is@google.com>

On 2026-07-07 18:42:50 [+0900], Sergey Senozhatsky wrote:
> 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?

So it was what I assumed. With that one static key it should be one
"lock-class" with several instances. So I don't think lockdep notices a
difference between index == 0 and index == 1.

If you have zram0 and zram1 and both have different lock chains which
could result in a deadlock from theoretical point of view but not in
reality because the zram0-swap never clash with zram1-ext4 then you
should have a dynamic key. That means add it struct zram and register
with lockdep_register_key() and assign with the lock as you did.

Sebastian


  reply	other threads:[~2026-07-07 10:02 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
2026-07-07 10:02           ` Sebastian Andrzej Siewior [this message]
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=20260707100241.zaM2yrF5@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.