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 CA362C282EC for ; Tue, 18 Mar 2025 21:09:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1A1B280002; Tue, 18 Mar 2025 17:09:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA3C9280001; Tue, 18 Mar 2025 17:09:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8293280002; Tue, 18 Mar 2025 17:09:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7FF35280001 for ; Tue, 18 Mar 2025 17:09:55 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5B5AE141828 for ; Tue, 18 Mar 2025 21:09:56 +0000 (UTC) X-FDA: 83235913992.25.516A2E5 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf21.hostedemail.com (Postfix) with ESMTP id 034C41C0004 for ; Tue, 18 Mar 2025 21:09:51 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZLEFIe9o; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf21.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742332192; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lYkMJs7lJvaItuq9Q7e32WJc4e/ws2RSpi2SeHLEIFY=; b=Z5s9byTn5NyZ+o7R/DjcFjBEXZsQHRl28QW8FQrKkF9GmzQIaTq9Co3ez5aWIK14nes5K7 29+F9sJJ3qGIP0r8zDP5YQZhl5CXbQt+4zCmqE8r4EjBxvvg9G2VHeqYvZpy3f/XKwy3nT xODnap/03AulGhbtmKeLIHE4e4YiZcE= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1742332192; a=rsa-sha256; cv=pass; b=gPFh1yKklTBdA13tR/c/zjJqRUFyNnbOi+nRPK7LlSeNytyUJsQRFoGeVoz6jI4iYPlE9+ OS6Rdjafm4wrYO/uHJySUibL4y2TfGOAKZg/3fFWMx+g8fA5Jio2QpJx4OUBcHEJ7bWWbk 6azIZlVXEB7KAg1fFvyjNYazAk1rDic= ARC-Authentication-Results: i=2; imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZLEFIe9o; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf21.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1742332192; x=1773868192; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BGEIt+sxtJTHcyAkUJM2MAaILEP+GhqXEnx0Ykvvb0U=; b=ZLEFIe9oz2bx5+7MSj7pblDluZOtL25zv+AFjCNOL3vI5i4Xa7UnO7Pe DTpCATZGuqPi1bBBu4XMPI8cM87k+NuYKwaeZ7yseq0jhs5jU9fb7fHH7 jcKk/11dZVWT0k3F/9LmmC8zfWLsSgFKuCCnQIPrZluebWuhkq1cOTwEw Is20H9Lmt0JQp0/DbcvqyMJhTdyAQbF9AXqKGPhwY7AZX4TTV+IxsKsUO Oaq7trI3xzOZrQdCYP6nPWKizqlJVQ8r9LOa2pc5z4yo5pilHlsZTBdHx Qy4Zg2elC2geJH3A4i6YruLWG1rS9ZwxOsYOAs+LWKGVxSdNZFZGmtUMO A==; X-CSE-ConnectionGUID: 9FUnEMOuQ9e8RKQZTl+FdQ== X-CSE-MsgGUID: beMT2uZ0SGicmamgmXKAdA== X-IronPort-AV: E=McAfee;i="6700,10204,11377"; a="54879957" X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="54879957" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2025 14:09:50 -0700 X-CSE-ConnectionGUID: 0pDWRxlHQ9mUprfdBTMCyw== X-CSE-MsgGUID: nZE7LzykRxOYOR2lDqGINw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="122851867" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orviesa007.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 18 Mar 2025 14:09:51 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Tue, 18 Mar 2025 14:09:50 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44 via Frontend Transport; Tue, 18 Mar 2025 14:09:50 -0700 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.44) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Tue, 18 Mar 2025 14:09:48 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ozovcj12GyIFbT8Y9wDFAhCP0UFb/If7bcBPGMCMkx+GaHzKHPkWhshj9dY8YAQSOobwwJTl+1UhNKCM9vl+GndqbYtS129uj7m0c1C3NB5BZpLBXSnM+1kMI5iF7roNAxlNatKKiDWi1Eqiw122iwKMCUE61JJfZEOp40ywCVEWtkpW9HhnGs3/ewZQkAgkVGw4d7KmD6fFOX5KlKeuPKjsOy/vlhs92UrX3EAZh3l63rTPfhSkgHb9R5vKwhX3yvgq5oGD9jKp4mxUcPnSK4d/d5KheRiwj60lZgN8uHHoZslqTbyYB0XblVHHOyGuZhwwRJu7GKwc5L1sICBssg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lYkMJs7lJvaItuq9Q7e32WJc4e/ws2RSpi2SeHLEIFY=; b=qe/QObpJHrcKsjOdU2EELVv3e0BLS0tLB9fRxUPN9FX+4PtU7HMrpcizM5GWe4XLSgiFEXbQW6yjHpAAfPBwg0ezjbVCm6ADh5boN7MMnTb+r8KKrW9R9HqXUC33M4JM2PHXNuqWz+1qbRQsqT3G78pWIMCKTTW1SZzcRgmSxwvwseCartSkVf3ESSv5R3heVZ+VtBlv2hMYwmr0jH9iQV2lF8pS/sn1N7F4aWqjOK7p4rrYC0tQ8GuWWtbp5vnyyaw1sD6o7W+XDLn6psQ8L71rUQGGQPz692z2Muewque8e5trs8P9x4/ucOZ6U8uzYjkiDrswD1J+REisEwQRVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from SA3PR11MB8120.namprd11.prod.outlook.com (2603:10b6:806:2f3::7) by IA1PR11MB8100.namprd11.prod.outlook.com (2603:10b6:208:445::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8534.33; Tue, 18 Mar 2025 21:09:05 +0000 Received: from SA3PR11MB8120.namprd11.prod.outlook.com ([fe80::3597:77d7:f969:142c]) by SA3PR11MB8120.namprd11.prod.outlook.com ([fe80::3597:77d7:f969:142c%5]) with mapi id 15.20.8534.031; Tue, 18 Mar 2025 21:09:05 +0000 From: "Sridhar, Kanchana P" To: Yosry Ahmed 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" , "Sridhar, Kanchana P" Subject: RE: [PATCH v8 12/14] mm: zswap: Simplify acomp_ctx resource allocation/deletion and mutex lock usage. Thread-Topic: [PATCH v8 12/14] mm: zswap: Simplify acomp_ctx resource allocation/deletion and mutex lock usage. Thread-Index: AQHbjBjx1q5dleb6eEq5EZF781nDprNmhasAgAA86hCAAVPdAIAAYjdggAQziACACyMtkIABOxcAgAAmLoCAACiqAIAAHucg Date: Tue, 18 Mar 2025 21:09:05 +0000 Message-ID: References: <20250303084724.6490-1-kanchana.p.sridhar@intel.com> <20250303084724.6490-13-kanchana.p.sridhar@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR11MB8120:EE_|IA1PR11MB8100:EE_ x-ms-office365-filtering-correlation-id: f21a43f4-9ec0-4030-4aa2-08dd66611e08 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?vHP3U3wwxufNtvvEyY+RbbxfG5fND1XHA4C/8kfim1uvFFGY/ZYwuOO2PmRV?= =?us-ascii?Q?7w/7LtCwVArE2lltB79RH5RcQt8ZxSKegMNDMSYkmzSFbvgnrY7W0vL1P5eh?= =?us-ascii?Q?X0A7AnpqSbyqmQC1LFAi8vk7LkkQIAp0mfM+WW91fMh3if0vdku2tWJpNQV8?= =?us-ascii?Q?m25ACqB3f4mxDztC2Ak6tc951MA+pBXWu31WaKbODGmvTI7c6KyoMB7ktNNE?= =?us-ascii?Q?l5QCcjBkHTkqsQ7hNPhlXUTb/EOzjxLKxwpBR1ojK/4TPB67RZQ0gx/TI+Jk?= =?us-ascii?Q?evlB/0wI4nRg/QAnYPHOrQYtzDdOOcU4mElXKR1LF70ZaLjauNao97fI7abL?= =?us-ascii?Q?wcv3KunWuCzhjCZgmu6UaPT39OP480qwreJE1zFQfoCsmTBdSDKeSG1YqMD+?= =?us-ascii?Q?WVaD2S3s97W2CLwg7w9ZpMJvOOd9S06w6Av7Dp94Jw+CEORyMHNEdoYEX0he?= =?us-ascii?Q?/QeNCQQxCmd2uDYO/prOoUF6tq8K0ZLu0qPO8YGocBmJuNjeXSrX64J7q9a+?= =?us-ascii?Q?tZA8UNCfA5R7/XWSCEiR1tByPjj8E/U/Fhfz2PWUhyKeVWNs8mga1gwpBZiQ?= =?us-ascii?Q?RvH2wi+zHHIPX8+ZfV7WCCCVHlg/EAHBsBKBLnp+g/m+WVhe55L2jr0LuKEq?= =?us-ascii?Q?hoNH2uhtGUupceJs46Y69rl8CzQ2h1cW+eHAMEjUrHWmg5nnajrhRHKZdJK1?= =?us-ascii?Q?markE2PMlye2JmURoE1slbrwOczVlYMe9EdqYiSs1Tf7v+Vo5pGuMM7LlOK3?= =?us-ascii?Q?cNqtaLBlpHgDzDU8qpclUQF/XNpyMnIOCFOFRmF8OZ5nv2RyPiabUgXHier/?= =?us-ascii?Q?5tRQK+3Z4p4w5i6u7pvbHTfNl0p/zC9CTyFJn0Sx9SuI/CnLzJYqviEeLsmv?= =?us-ascii?Q?lbrbuiUDozS7eX6ekhOO72s3j+b6VvrAI47PcSbCEgmZyip1/yPUk67fFalB?= =?us-ascii?Q?snmbOVbVtIZWk6J1c2XOmeGnVBgtenYTq/gxuiJh0U0zulJP2vf7Az/avKnB?= =?us-ascii?Q?s8QaieU6H0UQGdQL3aZSC/9RG3cEvBNbUhoxyF+46DnL+ZmatD/GaZK11tNT?= =?us-ascii?Q?aN5BA2nRK9AGL+R+XBEtxlqg59mC8Q211at3bfRmvyFgT+75AC5vL8wujfG9?= =?us-ascii?Q?H4r/BHh4lOGJH8lwXENVt6PLdVXPkeCvoY+a/Pz3wayFyQjhnq3VcxrUfyNa?= =?us-ascii?Q?hLLM9ZvRmzDxvXRnvHV3CydSgFHXYcZzrTO56hnVpVODPQH53AjDXiOs3OcQ?= =?us-ascii?Q?hiL0nxpxQ30QQR8+BZN8LRLxMhuNj8R0amZ3ALx4119QRxLpvM3/L2G9lW7O?= =?us-ascii?Q?Os9a5I4vChT0Tc6XtC99YGV/0kK0QMkH/7IjMQsXXCKAYHzH8nZZls/TNo+k?= =?us-ascii?Q?QWkItTzRogSN3BiOAdEmBmNh5UDcoRpVXw6G2k5splXS7f/7hMe6uePtlrBh?= =?us-ascii?Q?7d6I/fQoyUVEx2+vRGeyZniGLVvEKkVG?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR11MB8120.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?XH/sbnTeGss0T+SI+1e82g9iQ+Sj3zJRN6hGDBp92Xh8zd7UqIInjKB9Jvz/?= =?us-ascii?Q?FnUUfycBx92y69E/ua28OiPSqwXGCIPbYc469Ttzh6m5Zr0i3SKLaJN+jgtM?= =?us-ascii?Q?MjXNvHLAcgfOsCD55EM8iJT8zGkyT0FM4YdLbnUlcWoA7BHNhpvQcMC7ptzi?= =?us-ascii?Q?iXwjWnFXVH677LxoEMewaYNH8BfaoLPXao1UDZJbzfkevbL+3mP9Ha0Uvhht?= =?us-ascii?Q?bkTeXVmY8kd01jnChvItGkx0mF8D/j4ef+YsEcgN41bGEzBJzM6BP15jXaWw?= =?us-ascii?Q?F8cN6y+MIi15Jo4/Bo+BykiKGhfDEVITlEnb7yl6IQcV3MJ8JPjws5hG1ZMq?= =?us-ascii?Q?H87bjxZFi4Y3OE+dUKCCFtQpNGdGE6yd06q44Z4eFfiNFy4sOhJwG1RqA6EZ?= =?us-ascii?Q?wMKUP5IKzVXzCZvPY2eBA1o/QzvwCO9SLKJ9YRUsaxv6IO7SXJZ4O3G+X2/F?= =?us-ascii?Q?qahxYvo7FpCezz9ZesV7vLocyPR01HXk3nDIgXvrzvHaqyBOTdpLZeFw9RrA?= =?us-ascii?Q?EjUb5PmZEnJ5tWP6fveVnx/GHx/56GdLbTypijE/P9eF8UhzUmNkzMuy41LI?= =?us-ascii?Q?WyjvUNrKok+4in00MIUgabj7JDfC1iC7kL537RzqZMrM9Ic3kvlXJSfNAGid?= =?us-ascii?Q?+paytrLgyhnbSXrm1QBVIxc99IMVOX/8Vxelxi2BJMG9nGAbXzRdQohqw5ZD?= =?us-ascii?Q?Veda+i58Z4WacSWmNOECT68asEKnkuxOMqgo6CEoqMSKAwZuX5gIhB9VIA+6?= =?us-ascii?Q?xtSFSsriVyNTYbUnrQnT9CE/XPUSw5vluJQoGYqUYU1FBGm/MjRIx6/6vGSI?= =?us-ascii?Q?TJiybK/FeQ+0bhrjIVcOH4scYU67lu3X7+0AN/fgxJaZ6o6dFu0QwymzXpt7?= =?us-ascii?Q?LMHSzbXbN3Oyzu87Cck9WdUWXw1Rk9uiPL8iZtIqG+A1AfQ6Wby0sFYD2fpy?= =?us-ascii?Q?gumGQhSXCMgXPlvcn4H26lWs4RsCIn/Ns9hmUMn7Mm4m7RcQd9KPuI9AhjnI?= =?us-ascii?Q?G5PlvsSJ8U9SY1BGrAFtNrcQXkXpLyOv1IgUEege60PTPZxw4dw/I2XMvvhy?= =?us-ascii?Q?3o+ZRrY0g+QNMbZ91Uc4/RIgxAkqYAn661z5iy+gyTb21JwMnH2JvPROPw9B?= =?us-ascii?Q?2Sq6kkPuCcx4v7zC5j50Gw58Icpzd31VRhWNmobZG/KGe5riFOFIimkCrPtm?= =?us-ascii?Q?jsHETb3HIWQLdVSoAg/ZA+E0dUYFgCEIwmcN2X0zzW0+DHy//3T8VX/wN1Xv?= =?us-ascii?Q?SwHAcZ6lr72BgoQxtmOFjRA7/CUrW3jcY9Ux8FDRkZiVfo0rJy0Lok/i5MUG?= =?us-ascii?Q?KzZpCRHq7G0t1cRKm8TeF3wk690Vx05BKNOgpTI4qrMGb6VW8C5Ywdq/Ttd+?= =?us-ascii?Q?vsxu0My2oV7V5DuiPWdl8zSxwLKBp+joIMK7dAf8rkH7FaVEWoACgnoLUBK9?= =?us-ascii?Q?m2A178nULPNixtvy2iU3HrG3WxOcRaOOnVIpKCqiZ0B54PEsfBcZBzdj/r52?= =?us-ascii?Q?5HwkQ3okgDnp9TvSM7BbMk//0HVHCK6bnjoTUge6YjVhD1hd0Uut0F83IAhu?= =?us-ascii?Q?eXqsPFe52B1eK2N76f5uLnjLRsm0lNddZhNKLgwBlpIiaktVmU7dM0eo2YVQ?= =?us-ascii?Q?8w=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR11MB8120.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f21a43f4-9ec0-4030-4aa2-08dd66611e08 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2025 21:09:05.8056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cmZQ5CPrY/dMkRV4ne47SjAou3WfAmtSKkS/4LX4uswbtjB1jDJQSflckfloacRnJ5ajc97eAD6B9DYBVw/Gt9YR93NCvGj0XycKSQSCBy4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB8100 X-OriginatorOrg: intel.com X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 034C41C0004 X-Stat-Signature: acyc59t3xj54b6oky7m8yg9q44nhsmae X-HE-Tag: 1742332191-711275 X-HE-Meta: U2FsdGVkX19BP7bxcxl4l9Ap2rMVqJnpSPV6/fdlDcKg97XrI/xsCT/9svKdIiJcHNeQ34PsH7yzUDixTx+k8JMyiw352UgnWIwl+7H5IGjVhLqWYyjhmQogTabWgD5zXRYIz0tfXqVkHuXDG5Bmf5qRvRQwwWjadrwTv2I5aeZDjIz/Id6XE9NfTBHKnWItOFLpzojhZrCExmcacSqbvNWpFeZIf6h0zjGRjU4zzHCbEQbye8Kt4NCi8h+dJhLw7/cfX6N8tm4/Pd3ikarzJqZUH/wUA2Q5WsGgYz7/V9LNpo1V0ewjlQ8V9Ekh/9M/ocYGLLbL0oiunaUoR1IF2DqM15obz4MJwRB2Et/0UGi/CRV7TVD3rLZjQhjhijBKODf1NoQYEFAbQUuiK9MgCiwgZCX0zDvEfjcPkVz4V/JWENARVnUFCVQYonkhDrrE23BVlMmteLQQM0GBfbTDTIwnZXlJnS/pcMmvS+ZqvcYYmzSG9dEgh0D5zjVvXJST28WLjS11owo18iXiDtpQFgw22xjMrjwIsQwkgR4vSDA2/DMfjJkcKKs0+y25NeYvIlmlG/31jXZ5VPTLUmehUkkM/WvH4P8mFz5YJwz1XlNZjWRKocWK6ZkbJUEDRJgr1/lsw3ga0194UBzoWs1Ii9kDUSBWMwjL3FumWW5c5qvR9Ix70TtLvLgRZhaQDT7paEYNqYtIvyqBr+TothhUMreErpKPsCSE34zBhY82oudZ5UiFwDjgwPUhqLbZIIapGz3i6AYz5RYYaaNdV4+MWn3q6beggjBVB9nMrxk96ySOn6nmrgap8knp8/JFNUXUODSOEmGOHZ+MeTX/KZZOr1pRzFFVUoQWumuDR0q4qK7BAwUIZdLSlyb4Qp6sQD30Xwrh8Q3TeONMFbfAWiLwRuHQ4G2JmStx/nd65Y/lTrIjtHbw1uoOg+qBUE0rZQcqTEBhrRFXXszS7MTn13E O5Oy7x44 C8mWEo+yNEdeBvOZTiGJFIENQ189XUXv/FVtr+C3U5zqu5ov6vFF1wsfQao5nUeXw3gFoLkEqjOF0/4hgV4/rtON0Kca4ziVYThziB3wi+xu//Ig9sJs6sJqcabI7PbmdUjIgsXLuAZaQ+fpm+8tgCGchpDwju7sT3nbejQd+0y5TCQzupecwEXxjRS03XqbYQVR4gt1vnwuP3wOKl8ppXBvqiIdV3s72wwK5tGzc7NJaovaxJ/JlwdSFLzzBa89SwUUlnICt5pOkU2zu6FOmCi0bfZhuKvTkh5VAkZz/6vKQEp2hLO0FF3+MjgatOPw75LGyDzz1IC0Vr7m3eJo8Tf91mkgPXOQNO5z1muJrA30zQfUT8YmNKiMS/xcsuVr9PDsPJmBPIe7kHoTI29HHVAlGZdFfIsxgAGYt5XvplyHFS9lNVT/t6QaTl0PbyETpCyw9rzj86dSoN79IYojoiyH+4ngPVObOgEyCLKuvqbygt+C6pm03/aYfFFp5UfSbnj3sKnh+jr9gphYF5/gDU6TuoDUWX19mkNVZ+vgKEfgndBwybcmmLEjvGU0mxE+zxhCy+cr7XOLv3i//1MFuD2aY38c23AhmCGiFv6Q/c8FduFj1pAI6guy63oQg6BgClbKA/oqXsinfjaxvBeh1hfni2PWmeYUuP6FQ142SG/SDiTTl6MEhidE2caniG+BGzKVYBPxV6bHTTV2HSa6oV1CWCQgTfJZ9GrS6szWlHpA+jQ7gGccL46CRqBjDvmdPkwJSwylKMTm4PUjdeXLRQy1GbNbGij1P2Rv+fbJt2VkV3zpDtadIyP3hXGU+TMbAiBEKX15qxvWvdPo1Mkn/BTo63sRZqL45uCupTQjnx5gIfAJiQcayaYk3uZHYvnCI7Xl55+aAuHhFMl4i89hoC+b4ORA5Ql2DjlQ8xHRoydXxGDZPhyvy9wJUfb7FA/K/Y7XOGO1UlV0qiIN3PMj2gE4oelvf EREjLQnl BfxO96yX5Ip1xXIzIyHdN221prtdJaW+Tao7PQOivl8Niyze0CTF0IjTL7UmmMacMv7gxb0+8rCtBMSbXNxDJw06NuqL9wsJJe/zvI6Ucmk5QHDud1UPiEa7Fo1fBfys 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: > -----Original Message----- > From: Yosry Ahmed > Sent: Tuesday, March 18, 2025 12:06 PM > 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; > 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. >=20 > On Tue, Mar 18, 2025 at 05:38:49PM +0000, Sridhar, Kanchana P wrote: > [..] > > > > Thanks Yosry, for this observation! You are right, when considered = purely > > > > from a CPU hotplug perspective, zswap_cpu_comp_prepare() and > > > > zswap_cpu_comp_dead() in fact run on a control CPU, because the sta= te > is > > > > registered in the PREPARE section of "enum cpuhp_state" in > cpuhotplug.h. > > > > > > > > The problem however is that, in the current architecture, CPU onlin= ing/ > > > > zswap_pool creation, and CPU offlining/zswap_pool deletion have the > > > > same semantics as far as these resources are concerned. Hence, > although > > > > zswap_cpu_comp_prepare() is run on a control CPU, the CPU for which > > > > the "hotplug" code is called is in fact online. It is possible for = the memory > > > > allocation calls in zswap_cpu_comp_prepare() to recurse into > > > > zswap_compress(), which now needs to be handled by the current pool= , > > > > since the new pool has not yet been added to the zswap_pools, as yo= u > > > > pointed out. > > > > > > > > The ref on the current pool has not yet been dropped. Could there b= e > > > > a potential for a deadlock at pool transition time: the new pool is > blocked > > > > from allocating acomp_ctx resources, triggering reclaim, which the = old > > > > pool needs to handle? > > > > > > I am not sure how this could lead to a deadlock. The compression will= be > > > happening in a different pool with a different acomp_ctx. > > > > I was thinking about this from the perspective of comparing the trade-o= ffs > > between these two approaches: > > a) Allocating acomp_ctx resources for a pool when a CPU is functional, = vs. > > b) Allocating acomp_ctx resources once upfront. > > > > With (a), when the user switches zswap to use a new compressor, it is > possible > > that the system is already in a low memory situation and the CPU could = be > doing > > a lot of swapouts. It occurred to me that in theory, the call to switch= the > > compressor through the sysfs interface could never return if the acomp_= ctx > > allocations trigger direct reclaim in this scenario. This was in the co= ntext of > > exploring if a better design is possible, while acknowledging that this= could > still > > happen today. >=20 > If the system is already in a low memory situation a lot of things will > hang. Switching the compressor is not a common operation at all and we > shouldn't really worry about that. Even if we remove the acomp_ctx > allocation, we still need to make some allocations in that path anyway. Ok, these are good points. >=20 > > > > With (b), this situation is avoided by design, and we can switch to a n= ew pool > > without triggering additional reclaim. Sorry, I should have articulated= this > better. >=20 > But we have to either allocate more memory unnecessarily or add config > options and make batching a build-time decision. This is unwarranted > imo. >=20 > FWIW, the mutexes and buffers used to be per-CPU not per-acomp_ctx, but > they were changed in commit 8ba2f844f050 ("mm/zswap: change per-cpu > mutex and buffer to per-acomp_ctx"). What you're suggesting is not quite > the same as what we had before that commit, it's moving the acomp_ctx > itself to be per-CPU but not per-pool, including the mtuex and buffer. > But I thought the context may be useful. Thanks for sharing the context. >=20 > [..] > > > > 7) To address the issue of how many reqs/buffers to allocate, there= could > > > > potentially be a memory cost for non-batching compressors, if = we > want > > > > to always allocate ZSWAP_MAX_BATCH_SIZE acomp_reqs and > buffers. > > > > This would allow the acomp_ctx to seamlessly handle batching > > > > compressors, non-batching compressors, and transitions among t= he > > > > two compressor types in a pretty general manner, that relies o= nly on > > > > the ZSWAP_MAX_BATCH_SIZE, which we define anyway. > > > > > > > > I believe we can maximize the chances of success for the alloc= ation of > > > > the acomp_ctx resources if this is done in zswap_setup(), but = please > > > > correct me if I am wrong. > > > > > > > > The added memory cost for platforms without IAA would be > > > > ~57 KB per cpu, on x86. Would this be acceptable? > > > > > > I think that's a lot of memory to waste per-CPU, and I don't see a go= od > > > reason for it. > > > > Yes, it appears so. Towards trying to see if a better design is possibl= e > > by de-coupling the acomp_ctx from zswap_pool: > > Would this cost be acceptable if it is incurred based on a build config > > option, saying CONFIG_ALLOC_ZSWAP_BATCHING_RESOURCES (default > OFF)? > > If this is set, we go ahead and allocate ZSWAP_MAX_BATCH_SIZE > > acomp_ctx resources once, during zswap_setup(). If not, we allocate > > only one req/buffer in the global percpu acomp_ctx? >=20 > We should avoid making batching a build time decision if we can help it. > A lot of kernels are shipped to different hardware that may or may not > support batching, so users will have to either decide to turn off > batching completely or eat the overhead even for hardware that does not > support batching (or for users that use SW compression). >=20 > [..] > > > > > > > > The only other fallback solution in lieu of the proposed simpli= fication > 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 to= tally > clear > > > > to me if there is potential for deadlock during pool transition= s, as > noted > > > above. > > > > > > I am not sure what's the deadlock scenario you're worried about, plea= se > > > 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 wo= uld > > 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. >=20 > 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_po= ol, and will persist through CPU online/offline transitions through the hotplug interface. If this plan is acceptable, it appears that acomp_ctx_get_cpu_lo= ck() 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. Thanks, Kanchana=20