From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7213B3AA50A for ; Tue, 7 Jul 2026 06:40:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783406445; cv=none; b=dh+y086DOpr4JQhINdXvoWXdDS5WEdqFZQg2h6RKmt5C30v2g8FjWDisJ4fQb4a7Dg2t2OiPsgvGtxZMwd0KpX3VQEunTysu6rbhXULBGS7K7KnuOb1nu4TKa5mJbxc+BgJ1EtbNjdiZWYWFZhp+FZp1SoR7fOEF4Q8PYqFn3ak= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783406445; c=relaxed/simple; bh=SOeUSNPvLEDNVIbotW6MnU1kOYdx377Jt0KqhAjCJYw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kHayM+p1tGiXsQOoGDURHA0YVAG69RWKziUHgGBoLaP7IM6p8aCpVEja+kYnV5+MexSeuYQSTjZkHyhBN7BT+vtQn9Y2fql93BXC2zZXrzAbsRKvcHDJf7zAXoDfCxBhErdFzk2PzN8IdzZm8XHWb1JDPGl717sGiYklGK2Hyd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=aqiA0Q/D; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=DiBkaT/r; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="aqiA0Q/D"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="DiBkaT/r" Date: Tue, 7 Jul 2026 08:40:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1783406432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ObyCEryIwmniZMWVgbaPW4hyZdtbe1mtphtq19MumpA=; b=aqiA0Q/De1LQTMVcPL443duYUftLEhAds/ioHhSi9c7pBkHim65H+7Uiq16TWEmbFU2a1k p9uyVTd+wv4igg30l085v6rLL35cNoG3Jz+Tb3z2Oj6c5ZVwQ+fq4uPXCBy2Ky4Mys4Z0F AdZbyTrY/CmhyQ7lBF4thi5AyZYNilvoCJOxEbqZnNN8SHdDTuQzIYJd6h43sszuOQTEn1 CQzhfMOMHVdgdJgPIytUh95nEDxPC3ckFRNz/mkWJVgJHA54k9I3MnKTFNNikPMqK4iOAL 5WeB8G+qbU3Fpxowc7gh5SXyldug0VS1gqR00IGRL8tlN4r0YoxC+2eANjVnIQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1783406432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ObyCEryIwmniZMWVgbaPW4hyZdtbe1mtphtq19MumpA=; b=DiBkaT/rhrfJ64NQmFry1pmfAdq55vJHTJVSi7+Yu75tSJDOmYgcUqyioM8ewOftFnQAOO Pdei3mnVjhtcTMDQ== From: Sebastian Andrzej Siewior To: Sergey Senozhatsky Cc: Andrew Morton , Yosry Ahmed , Hillf Danton , Kairui Song , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 01/19] zram: sleepable entry locking Message-ID: <20260707064030.D843llKh@linutronix.de> References: <20250303022425.285971-1-senozhatsky@chromium.org> <20250303022425.285971-2-senozhatsky@chromium.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20250303022425.285971-2-senozhatsky@chromium.org> On 2025-03-03 11:03:10 [+0900], Sergey Senozhatsky wrote: =E2=80=A6 > 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. >=20 > Signed-off-by: Sergey Senozhatsky =E2=80=A6 > --- 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); > =20 > -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); > +} =E2=80=A6 > +static __must_check bool zram_slot_trylock(struct zram *zram, u32 index) > { > - return spin_trylock(&zram->table[index].lock); > + unsigned long *lock =3D &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; > } > =20 > static void zram_slot_lock(struct zram *zram, u32 index) > { > - spin_lock(&zram->table[index].lock); > + unsigned long *lock =3D &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