From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 311613BB681 for ; Tue, 7 Jul 2026 09:42:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783417376; cv=none; b=Lg7q7sNOyW9v0FVsvmJCfNfeAZpx3ooggLDy3uwUoNQavSVEkpXDnat0S3/27V0+bhvy1c6cHtQNkCOdMBwLQjk4oZXCrdmy9IxyV6xAUQUSSLj+Gzjb/mH4/v3+44jhsw+9FG6BcfkhxfBbv4l12VuHtXrQHgH1vW+/lHbm2OY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783417376; c=relaxed/simple; bh=HHlY5dDiEtlBbVN/lW7hySUj7lYYVdv84zYmrvZPQ/o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hublxdX7MHyonOqG2KYZpEXyzNB/IOo/I2Re/f1iWEeIxlaAYfZBnu3zCyAjJVTdhdHBd12bi8FhWWLWrhQoiaEF3OfnO/EQWFvOeUmUbMNX869R1Lv925Ocwol41/O4YumiJXPP9NXKd9rmg/zyY1zHIxteF7sDJ/uXpxG5Tps= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=HCweP2fW; arc=none smtp.client-ip=209.85.216.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="HCweP2fW" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-3856d6fbcb3so1828170a91.2 for ; Tue, 07 Jul 2026 02:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1783417374; x=1784022174; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=NG43xqiTlZetTkoltquLMxLW5gZsV1d7NlplgwQVb0s=; b=HCweP2fWPc8v8nikSzdLEDBOOg0cfJIpy1kR0QJBeliAr1Ku8Fr0v0D4a1Dshs7xM4 szFPNbt8TL3BDQ3B1DI3f+BL1Upwgn86WxlYDvdFiei6T51b64rRl39kC1tLmn6Ym7JN kJlcjF9Lj5grVjIEDUtrLz0UgYnuNKEgKT49c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783417374; x=1784022174; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=NG43xqiTlZetTkoltquLMxLW5gZsV1d7NlplgwQVb0s=; b=KEL3xDYjVjDURPum+Gt72VXKmILnMGHMrvCxGrcrDwyyVVZ7S/QvJ8EghcpJDLDaTb 68smH0ejStflv9mq1C+HeM4XmZuJbi10Nc/sfqIxlFcDG3x/JkG6Wvt9C8vBStLbkVB7 9VLqKhUcjH5MOC/q4dwHDMotDf3qq7ZX14r6n7JUNm8z09gsptex9lIN9pM0bWiG95yS 3PI29ZXLnobGI4lKWWLNidQ069ilxrXSMVCedc4oNfI4EOeU9xldNuPPIgTdDpJ/OX8z SP8XfQWwwb16z63qOzLz/aTD4fbQHYvRFoMr6zOxvU3ipnrkhTM8Fy6FztAXrp9rrA9f wHTw== X-Forwarded-Encrypted: i=1; AHgh+Rp8o540DRlqKTkGqi83tVbWYrrtIDCNVftCEVHSMiZLtRqUWXuC1EZmEPYCI060Qjzr71aMYhWRe7tYSN0=@vger.kernel.org X-Gm-Message-State: AOJu0Yyj72saumlcjy3feklgqYXoSkJuGyKOldOCDBkVvTlz52LvvvXT QZUv2l9ezunG2+WBSY37GGJzA6iHYyfqS0iSIsf1U7C3HpKdnC7d6jbGbZy6SPr5sg== X-Gm-Gg: AfdE7clezdiPmAvywMyXdh8bDNJdWo7jPQL2iXdYCn+pNIf4yk7kAl4P4OzGxwssvaX 3lqlTkQLYWE3V9aOPXG15ofiALS663sjJEQona//HYhbXK3uMackVW1EWtdToLiCWrfX7UGQO4X TGfabbDYJSnpnxJDTp6cIpGZ13t5QmsJKqPfKhYZnxIqlNdkrjQHSND1THLtUY1/Oh4sgQ3E6p1 Y0Ez5Xd5YqPLtQ6s16uPN+lrE1jk9Ofk2P516uD2ueEsQUjtbk8vs38pDHJu98M/rdr0Vbm5U7+ JXcf08zcKLT3kzj+ve6zaiiXj55ZjAkZuY0J/wtAnsg3Q6qFr2ubivJFcASYiHwUc1vt/c/9XEu /G+RiNWzG7ZVIt04Bc6xpTtRrt9hDr6FrMmepgeC9YTuCU/WJa53CK8IHq+1p0J/vWxUfJSEuYk T9kFI8f4OTwdevh9/b7wT0saStn2sGRzVPg/n8VLP+9XijuascPM1x X-Received: by 2002:a17:90b:3808:b0:37f:9cdf:f037 with SMTP id 98e67ed59e1d1-387572b3d9fmr4095937a91.26.1783417374535; Tue, 07 Jul 2026 02:42:54 -0700 (PDT) Received: from google.com ([2a00:79e0:2031:6:d4f4:6328:49c0:b912]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-387d20a2f2fsm797739a91.13.2026.07.07.02.42.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 02:42:54 -0700 (PDT) Date: Tue, 7 Jul 2026 18:42:50 +0900 From: Sergey Senozhatsky To: Sebastian Andrzej Siewior Cc: Sergey Senozhatsky , 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: References: <20250303022425.285971-1-senozhatsky@chromium.org> <20250303022425.285971-2-senozhatsky@chromium.org> <20260707064030.D843llKh@linutronix.de> <20260707093024.DPG2lvt_@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=us-ascii Content-Disposition: inline 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?