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 D2A86396D13 for ; Tue, 7 Jul 2026 09:30:27 +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=1783416629; cv=none; b=nirYv2fATdhw/sIBrcrm23zduY71X2AtOJ53Qo7/boCCYCuSrFcH79G30R0IUoCHONv3u7bmvWOtQTGNS2kb0QKuP8JsUNfVI/blRv+03kk7tAtLV2Oa4OCiCtaipLTwuxdkUNBU//FJ27vgjz8CeKfk3ICTfrWlJkOXPanuoZc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783416629; c=relaxed/simple; bh=H/koIg6ezJHG2DBBiJ6g91fbaUvscpiri45De52korY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b0i0/LUbVfpv3wxBHz8iF2pbnzTClR7i6Kf6SDjWTnvnCXcjVNacjj5mH37clcBTfMTdrQaoDNQkg7F2AXyAdjlkEu4/E5KqHsAJ6jNMR61JR0FPJG2wc3ax5C9853f1Uq+dO/gPKZTksom0RJLFPG6tyKCZY8hu1M/S6XK6Fnw= 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=ZXplErFa; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Vm55d+mz; 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="ZXplErFa"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Vm55d+mz" Date: Tue, 7 Jul 2026 11:30:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1783416626; 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: in-reply-to:in-reply-to:references:references; bh=0Z4cc2eS0rwx5IwNb987CsmY1noqcB8io5t3N1GtK80=; b=ZXplErFaCfJtnofpQhPfScbWI5IdUK2H89VV+Xunnn/KIR4jTTyXZhIzQDtgACqFHq1plJ u9UPCgMq0Cu1Q8WI5aeG018TK9TVYApZUCbwuUIxzkh25qPVIz872R5sj5K1ZjA21xpAzE EldNfrx42N2pWW4jvLnGxGbbZZW4K/rDvNVcyIotFW+ovDlhk94DpkRTDkuWeujHFJHZ4G GHWU9dipPwRYQ3K5nTJW5t55Sf01YL+QVdGVyC8/dCH3yKOm+TrNGtR4TvfnqzyglwqBaZ BM89CufGHUOsIy4OLjdT2idmM1fm0WhyceubntU0K66J9dZm8xCaPIsje5B6PQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1783416626; 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: in-reply-to:in-reply-to:references:references; bh=0Z4cc2eS0rwx5IwNb987CsmY1noqcB8io5t3N1GtK80=; b=Vm55d+mzQpWrPHxsz83nQ5l7qL4+ICHzbR9+xdGQDVGEDo1qV03otXbIs3E/Y0yKzctcVg tP39sWxZz+i3JWBg== 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: <20260707093024.DPG2lvt_@linutronix.de> References: <20250303022425.285971-1-senozhatsky@chromium.org> <20250303022425.285971-2-senozhatsky@chromium.org> <20260707064030.D843llKh@linutronix.de> 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 In-Reply-To: On 2026-07-07 17:15:21 [+0900], Sergey Senozhatsky wrote: > On (26/07/07 08:40), 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); without nesting. Sebastian