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 E9DE0C282EC for ; Tue, 18 Mar 2025 23:14:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EBA4280002; Tue, 18 Mar 2025 19:14:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89A61280001; Tue, 18 Mar 2025 19:14:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76427280002; Tue, 18 Mar 2025 19:14:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 59583280001 for ; Tue, 18 Mar 2025 19:14:14 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BCF721609C9 for ; Tue, 18 Mar 2025 23:14:15 +0000 (UTC) X-FDA: 83236227270.08.74B1E55 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf15.hostedemail.com (Postfix) with ESMTP id D7380A0003 for ; Tue, 18 Mar 2025 23:14:13 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=qyjvjCTC; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742339654; a=rsa-sha256; cv=none; b=yHk6R1IACG1izcWjWkPew0OpgpxpSOx4jxd7u1Sq+nrUEp4bPrEkLYyCNdX8W15L5kaOCa 27FG0LC1V2mps1cOf4nF+LV5G+qjKS2RR4yUR4u1TOFhicBy8lduxkhLwIcdFJq/iW7ssP x3tz+gacVQ22UqLYmXeSWYl5+ROXW10= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=qyjvjCTC; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742339654; 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=dEiwYqhjF6BNFFV7jF/tNDaFFyAW5VoJIlRl5arxgCo=; b=Uu1jR7I7ABusDwhGibnhjQQ3DiQsf/Mgp1NMnhXIzaLJOPQIclFJmQUPLE/9cum7ysrVIx a1KYJ6Qj9Ozn0PM7cG/NKswoGs2oGj8LIvS+UhBE6PVdHjosiyGZECcyQyzPR8OVVUxAtX nZNV2TQ0Hp3qOlAyqZw7Hqk6CmmnWg8= Date: Tue, 18 Mar 2025 23:14:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1742339651; 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=dEiwYqhjF6BNFFV7jF/tNDaFFyAW5VoJIlRl5arxgCo=; b=qyjvjCTCIdIj6tib4Mpx1MGZVLigYMqTgWhVDJLgUnsBfKxMAVv5fc4xqsqz3ChWfTd9e6 lPCdLPV8yHofkDykLWTZU+hTpDbLx/coTbGEGswaJ2onXy/8xpE3exzSWBbdK0/+N+bA9E veji6WTR2Lcpt+1zwEQft4Ud9/V+tnk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: "Sridhar, Kanchana P" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "ying.huang@linux.alibaba.com" , "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "Feghali, Wajdi K" , "Gopal, Vinodh" Subject: Re: [PATCH v8 12/14] mm: zswap: Simplify acomp_ctx resource allocation/deletion and mutex lock usage. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: D7380A0003 X-Stat-Signature: ggg6bt5jty5w3ihnu5bg96dyk14x1tmu X-Rspamd-Server: rspam06 X-HE-Tag: 1742339653-278193 X-HE-Meta: U2FsdGVkX1+lK7UVNFQtJnl30iyqnhWxzbc6BHyLZR9l92n4la1k0i8Y7DzIaS34yrBErw1kxaTDoAwjcsXTrNJUHQNQ6XCzk1kIEXLeczu0SuK1SZINJS66Ua0RHA3ukWjroseHhyPs3+EdgQSfv0TvqayZwqK3//S6wUW7tciKQ1EhtjwLyuApINYw6NOxiIBxdfY0E1Dl389Ny7+qNgEpWT4BzAPH9s7vCe7hqIwTgKyNQZz0/4j4yH8+gRzxfFk9RbsI8Sc9bAzPsy3DCnFMY5NSRIzvJwq3zFMmq9QXISOMDDCQiDpFcPBFtXKqHhvpOBZXy3leH9GyYKxYAd06Gwcx6MgAghOarYYu5Nz7K6qCdhMsHXubnTA707+P+8wvSkF+PM6Ih3nQF8rQ6UxeEkRLrX25GQlx/16ROvWJMZi86oq0nms3Rljqk+UwUbhKwQdeoP2YniTYvLDAvmMSdDmYjM46aLr0oMLhYlvBO9mrWc1FIE6n55SPfBBMFAMlO4JhlxnhW8N4FHOkbSpXlE8D3v5Bz16dOVWnP6SRF5TAyR0hfV5zBUblcq2dFwb3IHfbzEr0CPbEqrZXhCKS3r4xXJcCHwHEMIBX8Fg4PR3xaixPWcyt8jamH3Z8I3rbrqq+dE82x6is9gE00uafH1P+tVb9aY/1S3ap3RSJaINhOJc1MYmGnVe5kZ6cvVSbDYu0iJd/j/VmfB8DDhdnDtyyaSDLa82KgoQlzfayJciO1FI8TkyED1aOHkJ6X2E3VbjjcQjz9HI522oOTfxAPSU9T2r80Sdn5YgPDRglQXElItOS2U24S48S7nJCdirsAq5Zo2njiD44FfJB7BCFmx/2sB0brFEG0OmDAr+AW7jfl3uO4suVUV8AmTd0uebA7nal0LvGauU/6joEaHRXjpQVLFPhNEh5NMGpZYiMm3wgEpSfwjpsHx+wXCX9YCiiVRsRBOPRBZ3ZnYC yZBBGQXj jpSjn8jyLmR3xCFd7NdTv/+U/kGLHH5i89/+NlyzIGAxxEXjEZFfcxVheoX1Kb0MlCOSAzK97L6blVBjXB+4A0xqsoVgF0qonMWEEs/nyY+bJ/1WoJE31MV9zCCP07ZxXUuXQ8w2NHDSCXPZ6MLXU6Y5fwHqMJ9jd9JQvtuYi8mLqAF5/tN44l9GayenDotkoWDZH9l6b2SQRt/ubWXnVZ8haFD4hYY2mhhsQ+hItdoM6q5gKBSH0oczf/6w68SADzQ3CZr9ms6cXK82kHPBTMVdjPV1xZ5MDIIcg9EjmWyYPXgqo5Sr6syMJqA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Tue, Mar 18, 2025 at 09:09:05PM +0000, Sridhar, Kanchana P wrote: [..] > > > > > > > > > > The only other fallback solution in lieu of the proposed simplification > > that > > > > > I can think of is to keep the lifespan of these resources from pool > > creation > > > > > to deletion, using the CPU hotplug code. Although, it is not totally > > clear > > > > > to me if there is potential for deadlock during pool transitions, as > > noted > > > > above. > > > > > > > > I am not sure what's the deadlock scenario you're worried about, please > > > > clarify. > > > > > > My apologies: I was referring to triggering direct reclaim during pool > > creation, > > > which could, in theory, run into a scenario where the pool switching would > > > have to wait for reclaim to free up enough memory for the acomp_ctx > > > resources allocation: this could cause the system to hang, but not a > > deadlock. > > > This can happen even today, hence trying to see if a better design is > > possible. > > > > I think the concern here is unfounded. We shouldn't care about the > > performance of zswap compressor switching, especially under memory > > pressure. A lot of things will slow down under memory pressure, and > > compressor switching should be the least of our concerns. > > Sounds good. It then appears that making the per-cpu acomp_ctx resources' > lifetime track that of the zswap_pool, is the way to go. These resources > will be allocated as per the requirements of the compressor, i.e., zswap_pool, > and will persist through CPU online/offline transitions through the hotplug > interface. If this plan is acceptable, it appears that acomp_ctx_get_cpu_lock() > and acomp_ctx_put_unlock() can be replaced with mutex_lock()/unlock() in > zswap_[de]compress()? I will incorporate these changes in v9 if this sounds Ok. Sounds good to me. Thanks!