From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1189C19F32 for ; Thu, 27 Feb 2025 13:20:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24C66280001; Thu, 27 Feb 2025 08:20:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FCCD6B008A; Thu, 27 Feb 2025 08:20:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09D56280001; Thu, 27 Feb 2025 08:20:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E0AB26B0085 for ; Thu, 27 Feb 2025 08:20:50 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A5FA4C161A for ; Thu, 27 Feb 2025 13:20:50 +0000 (UTC) X-FDA: 83165784660.03.0F9FE74 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf02.hostedemail.com (Postfix) with ESMTP id 697C980004 for ; Thu, 27 Feb 2025 13:20:47 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Pqqy2blC; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.176 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740662447; a=rsa-sha256; cv=none; b=1XQfj/k62OdBR26kajyvKqsDQiTIIEcbEadCQPOf04REQC0O9EH46sMT/UpD4rdPY2V8pD 9bzeDIf50KprSuL0qKJhj8/3IQQ6o/vgTH/8XP7UO4P/S8vAbfzutBfN78QcY9ET1WwVcE u9yi214S1LhxdDeF8tc9UmqLIs4A7aY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Pqqy2blC; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.176 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740662447; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=k0X5NRD7qbqiDiJP/6CHajV83B5iot3wBBgQ9wxynos=; b=F2XijfRiYKvZQrYUSf4cd3pCO45Ycy5bzbG1bvA+TehKAp+0JpxP1ptUUZvu8hxJo8WJkO ubyocU1AJv4T87Y9UQK2eeXnamaqpUVZe/58e1s1MTeXuhTl3ze0+1jo1hGIJqJBtInCUc 8S8kc3b5vf8Qjvdim/27KbajhnG6ZzQ= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-222e8d07dc6so17063055ad.1 for ; Thu, 27 Feb 2025 05:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740662446; x=1741267246; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=k0X5NRD7qbqiDiJP/6CHajV83B5iot3wBBgQ9wxynos=; b=Pqqy2blCFkg77bfohMz4cn32P/tKgUwKNkRAyiPm1HhwK7v5WRR1fo/q5xMCeo8laU 8oKQssL0SlQlhxjXDdFCryxEBxLlMPb2T4opqnmqE0D/fbNGMheZcLCtZnFSXIRULJLR ziX6OoT4F6RdfLy7A1s6UmQsbwKcgtMHx65aY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740662446; x=1741267246; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k0X5NRD7qbqiDiJP/6CHajV83B5iot3wBBgQ9wxynos=; b=MALnzh1CEwwXtleVtf1A+v82NMSFz6YaANLZA0Y7jdFtAGwq555/QOesLwqC8lqRBH j7v/6feWUZ5U1Vfb3RNmSQFjs6TRPbsZ8XOAhs84CfeSY/IzLx9gO7+KmURkOS3ukewL uDjiFPn3C81PZYAPoFKoZCA28pGEkV6VWjbOUjqtvy2uuZVcfWgjLFN+zxTrr8VOz3bi E+7u1lZAtrPwkDlTH2HiqHTZhTwO9TrPZOCxesFrSeWHkAjKEZ6WQRkzkZThNe/i6Mr0 +qVVcUs9yosr4pn+UfuN9wd2tPdzytwcy3DQyvRUXail4EVoSyF33KRTiBtAg2Dz7ADf poDA== X-Forwarded-Encrypted: i=1; AJvYcCV1nnbDjy9/jnDGLWNVjPB/r9LIlpIiFlb06ZDSir7l40/n/RRzwGCz68fI68XJlGWEo/DI/jMQzw==@kvack.org X-Gm-Message-State: AOJu0Yw77R9lyrOlpffYmNO9Wjyfhkobwx7AUX/O0lXtBErovfgOHu9Y +2/SpiiDixNuoLP/B3+/MfVd+ia1gt/JyG/bC0Zc7OpALo5Li2AqRrXG71RZOeIJSP1qHRenWxc = X-Gm-Gg: ASbGncsFxyBBYyX3j4Q5HHiz7pZYjEsTRJqUxrKyQ1vOnPBnbGOwgpi5Kadkfn+f5xZ 1363GC2nZ+Nt+mlk0PEy2p86/LvIITYDKbTNfOwy4SXgeSYSPGgtrWWk0wddlBIydNAENqvYfoy 37IX9jIdz8KdhlaPOQ9gW4/6kzF6GrmTlaQPleBkf+gFNaHLgStXzXRcQomJvgUx8RE9h+4FCVV A4BG9aCwNcEJMm+KAreMj7b+Y8aM7ROiCFYT4ISCB3FfzrJRslaLupais2E2awiPga0SHEY10sv blsNSlj1P5eY/lg7XuSJfHWn+vmRbQ== X-Google-Smtp-Source: AGHT+IG++fNxUGLMn5iiBI3kkDvuQHaieV5JWml7A7GasfzSnf9frDmJlQk1q3iU9FLDaJxew95ddA== X-Received: by 2002:a17:903:1984:b0:221:751f:cfbe with SMTP id d9443c01a7336-2234ad4e189mr61357585ad.19.1740662446124; Thu, 27 Feb 2025 05:20:46 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:a9c0:1bc1:74e3:3e31]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-223501fae29sm13965295ad.95.2025.02.27.05.20.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 05:20:45 -0800 (PST) Date: Thu, 27 Feb 2025 22:20:39 +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 v8 01/17] zram: sleepable entry locking Message-ID: References: <20250221222958.2225035-1-senozhatsky@chromium.org> <20250221222958.2225035-2-senozhatsky@chromium.org> <20250224081956.knanS8L_@linutronix.de> <20250227120532.OsZr4v2A@linutronix.de> <20250227131253.T_S_Icyt@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250227131253.T_S_Icyt@linutronix.de> X-Rspam-User: X-Rspamd-Queue-Id: 697C980004 X-Rspamd-Server: rspam12 X-Stat-Signature: oefaggkq41wwjzenbrgytermqwjf9xm4 X-HE-Tag: 1740662447-679765 X-HE-Meta: U2FsdGVkX18tqnSW2Tl6cU8QatNIZi+8kRVtW2Bc1EuiPoifrSIyJqLYeiBzND7JDqSdd8vKpGW67kal4TYm4uOy+GwRIpqiVRls0zV7lxUmRGMRwNgHT1rKUAzO+5SaVFpXWwxd4DyHeav2p02W1uHurDhYZqdXZK8wgER/Hk17mHT3C+kTIPra4PZ5ZMDk923VYIlNvxzaSHswmU53mb9eXUECvwJuK9SWCJUGfgccLjJ022pkwdMzAgntIxSO9071h6yw58D9ehSj6iH37uOXEtHUbBuklrsO5OkxD708mYqQlmGy1ryqlRHH6nBM910Khgz2ZmSom2Jt0Ft7aZw4HwKcpS9bD+vu0xm+JaGDynPTMqU2sjideO1ZulMyYpNfkkiTNOFYKjYV9HyBjEYr1RC8EqLzPXKKUDcaTwlm/sLxobAzdtwtGpE6CABNowL9JZg0KWKIFQmBCHBMamkRKOuHQYHoz7wM5ZV1LTXd6y/PU3xoLVR3g9Ln4SjB8czON8Jm13SQxgn4TqSbdQohx0xFjhbJtyQ4GNeFwoFjmY+P0ySR7OillKctbp3RiiYe/7daqq4s1o1X4wZzHG5LaW4DLFDQ6xiommvp8tlB5asIuFWM0+w8xSB3Dx//UHZFWrhwIQm02nRuQNCpmsWEf+KrwutBv4Vl8mbfB7IZE/yr2uw92NZMoS+y9UMSxnUqZkXbBFXahJOie+q32IDx8+eyKH28DtKSbgh7QFT7J8BrAsBMXMgudUyHOg4PXlrUMRYaCZ5uci5rlJ50xjmA2n362w12pOXI3MaNvJENkfSVjXTNKKc5ognVeVt/GvwNq/efID9adZ/DjFpe/iIaGM58k46N8yDZg4VhyZVZPbMQ5yJ7cbp2CLKFiybF9KiYOJFn0r1uIq2VRw9R3gvd20hkplg1cBLvXav60yegCeV7LEg9H3v3v4vuu82NljbXlBAjIQ4mktoE0nO GbZvPOyC Vo8MbHFTT0qB09KwvQ0XJVGTmqpNtEo9UdVxwOoKTYms0PZnxetnoxsV4Ux3TdMMIAPxI18TMbkqcfV1auiq3uXMWU+00VzUKcDK37ciWwl92Z2igiHvFwFblbl8h2UV9wS4tgcah1d0WhKReyIBf8J9SWX1aU6stsdn2dKuNKpJqE3Ev6Frdvc/IdU7NRxgsU2tYOFYGBWFHG7G9Pr6Gi2mDLZBMS5OUpQA95c9xpI1Cv1T5KQEi4bKhBNjgDLdSCURIUCCxIndZYtF4OCIsHEIUMUQYquuYgsMd2B8sY7nSgJHoY5lcTypwteo9pmoLJ+eCU2XeOzwZCySHoQp1ogCdJBewpjmFQ5r3CWZlbDQgCgg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000208, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On (25/02/27 14:12), Sebastian Andrzej Siewior wrote: > > > I see. I thought that they key was "shared" between zram meta table > > > entries because the key is per-zram device, which sort of made sense > > > (we can have different zram devices in a system - one swap, a bunch > > > mounted with various file-systems on them). > > Yes. So usually you do spin_lock_init() and this creates a key at _this_ > very position. So every lock initialized at this position shares the > same class/ the same pattern. > > > So the lock class is registered dynamically for each zram device > > > > zram_add() > > lockdep_register_key(&zram->lock_class); > > > > and then we use that zram->lock_class to init zram->table entries. > > > > We unregister the lock_class during each zram device destruction > > > > zram_remove() > > lockdep_unregister_key(&zram->lock_class); > > > > Does this still put zram->table entries into different lock classes? > > You shouldn't need to register and unregister the lock_class. What you > do should match for instance j_trans_commit_map in fs/jbd2/journal.c or > __key in include/linux/rhashtable.h & lib/rhashtable.c. I see, thank you. Let me try static keys then (in zram and in zsmalloc). Will need a day or two to re-run the tests, and then will send out an updated series.