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 235FFD5D696 for ; Thu, 7 Nov 2024 22:21:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76A266B00A6; Thu, 7 Nov 2024 17:21:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F35A6B00A7; Thu, 7 Nov 2024 17:21:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F6D66B00A8; Thu, 7 Nov 2024 17:21:19 -0500 (EST) 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 242FF6B00A6 for ; Thu, 7 Nov 2024 17:21:19 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8EA671204D9 for ; Thu, 7 Nov 2024 22:21:18 +0000 (UTC) X-FDA: 82760720700.29.05DA006 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by imf10.hostedemail.com (Postfix) with ESMTP id 42329C0014 for ; Thu, 7 Nov 2024 22:20:58 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dmPjQm8F; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf10.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 198.175.65.20 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731018024; 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=nKc1IEfuhkuQql0fp/oMALWM9XpgZ9scgKJe6QwBObg=; b=ESxXzHU4oeNWsq76ftp4aaqGffhDlVTp5SxUXMfXrgEre4p2koRlMfjXgl5tpICWKnqtZL 5tQoF4NBI9fTB7xqJspFTWrWpYSAPkVCLc0p3ULGoAuWmKJp341QRlhcyTb6dWATlI7YMe 78nMetiX+4x4j7uvpjS9ez1Qtc35IMM= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1731018024; a=rsa-sha256; cv=pass; b=ichIKqk2LJRNvsUV+dOeox/+BKGoV3AdXNK9l4ZJ5Yj3Fd+OM0ekA1MOWogEb6b5LOZzfc 1zamJqLKvsRlEEMxqEcUqOJDdn4TWMdm9Q+IsNL03ndms+F8zgaHt/ab2gO3ZJjUkicB/3 U7G7LexYD93NR5AXru6ueTFQoU1xfd4= ARC-Authentication-Results: i=2; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dmPjQm8F; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf10.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 198.175.65.20 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1731018075; x=1762554075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NkI5Q8YtZNTEFhhfiePd3WW60qO4wQvKofHKaYHeXo0=; b=dmPjQm8FSgtcDMLIllHXyzcAg3pMSTwGr7IIil4fjsSRFM5O0nV6Ie6N ARZYQ0rFfO8K2LIZQzOZgn+pdTZMysId2wI+UqwlHE8yfdQ0p4qmgYBB/ N/ybb8P90EQsQ3CRRm1nNDnFBBW1P3cZSmez8lD1sq57ZswrLt65vaFuz 5Ln3tSRcNM0VwwI7TkDTZATfvGZRMD/GMmG0/cIlYuLCKtuQgT8p9V7k1 kZqIGvcWdDQyat5pAYxYRQfc+lz95AaxRxs0+NkZeHXwmY3uE6ozWYAfO jBNN8KRie92ZXe+azxaTrqXnrnzM9cBIpxy5moIu6ZWXPr1zJyaTSZ+0G g==; X-CSE-ConnectionGUID: NT+D9ElqRaiToz+2kRnktw== X-CSE-MsgGUID: 62tlZhu6Ti2KlfVFvauX1w== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="30660113" X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="30660113" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2024 14:21:10 -0800 X-CSE-ConnectionGUID: DaEOUmPUTn2aVAOe4F6qGg== X-CSE-MsgGUID: SvSJ+CS8TKOb4I/tUmU/fQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,136,1728975600"; d="scan'208";a="90385026" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orviesa004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 07 Nov 2024 14:21:09 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 7 Nov 2024 14:21:08 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Thu, 7 Nov 2024 14:21:08 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.42) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 7 Nov 2024 14:21:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GKIA58D2qiBSSmg+gmDfFnY3nVy6IDZ+AeC0rSyuRRAJcfDgQu9Nkuc/PTpyqD+fpapcX92djmBI6icqcenYFQn7XYjpUwdYoNFffd4rdWUFJp5hvgpLiHxIzP9tMgFNN95u59qg/x1hHBO6cS7d5gX7QnLh9+GyeRTiTJYR5QwYvgC/i19YGdsJiHvYs+XoSFhFinbddpx3AsNn7KmpQ3Df2IM/cGKBP6T0WkJMfurfV55/gWNAbYiYoz264AjpwQY85I5VTgo3v70hnId+S486q4JvDCh2GRbYplrPxzT3cPIxfsWTkCgImjsR538ORcpFrlnQUiT3JYVgpif5lw== 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=nKc1IEfuhkuQql0fp/oMALWM9XpgZ9scgKJe6QwBObg=; b=WmPIi98TcI42dJ6JT1ar0OmeDEy0kZGw5k4IE4c5avI7p9T/h/vIbMszYdloHMt/QjeFmW0XzlvNenz8odRqxlFlMbP+CI3qr8YkodCMvrerzSRf6qqVPsZnIH9zSQBUke7qSNPjLZ5QJTnhA6lTz8L2pV+jNzeCVy2mwlRVZeubx1NOf5qpqozAlHj7P3CyZH2jfiVH59MhBEWfrSkXx3lAKWUyxMgi8v6OvrmbcBypKSW83MG1ETzaAUgHCJNvc4ttSpENH6o0s1IEnERMzKjWBYw/IRkRPIi9sWbPYr2J/Q9BG3varMACNmoXQavtm435VOIoL8B661Qq+sEFCQ== 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 SJ0PR11MB5678.namprd11.prod.outlook.com (2603:10b6:a03:3b8::22) by SA0PR11MB4525.namprd11.prod.outlook.com (2603:10b6:806:9d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8137.19; Thu, 7 Nov 2024 22:21:04 +0000 Received: from SJ0PR11MB5678.namprd11.prod.outlook.com ([fe80::812:6f53:13d:609c]) by SJ0PR11MB5678.namprd11.prod.outlook.com ([fe80::812:6f53:13d:609c%4]) with mapi id 15.20.8114.028; Thu, 7 Nov 2024 22:21:04 +0000 From: "Sridhar, Kanchana P" To: Johannes Weiner CC: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "yosryahmed@google.com" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "Huang, Ying" , "21cnbao@gmail.com" <21cnbao@gmail.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" , "zanussi@kernel.org" , "Feghali, Wajdi K" , "Gopal, Vinodh" , "Sridhar, Kanchana P" Subject: RE: [PATCH v3 09/13] mm: zswap: Modify struct crypto_acomp_ctx to be configurable in nr of acomp_reqs. Thread-Topic: [PATCH v3 09/13] mm: zswap: Modify struct crypto_acomp_ctx to be configurable in nr of acomp_reqs. Thread-Index: AQHbMIERO8oD7n2rBEKiN2M+KhtYprKsEc0AgABO+cA= Date: Thu, 7 Nov 2024 22:21:04 +0000 Message-ID: References: <20241106192105.6731-1-kanchana.p.sridhar@intel.com> <20241106192105.6731-10-kanchana.p.sridhar@intel.com> <20241107172056.GC1172372@cmpxchg.org> In-Reply-To: <20241107172056.GC1172372@cmpxchg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR11MB5678:EE_|SA0PR11MB4525:EE_ x-ms-office365-filtering-correlation-id: 26b6a723-4023-439e-b828-08dcff7a7805 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?dwL72CAmvZrp935IOve/zUc8FArNa2wLEEoU4JCNUdEMLCdk18xgjYpSk6O8?= =?us-ascii?Q?OUrIUsb52oB2Mw9gDbEXUUPv8gyFohc5nHpKnR92X7qDEQXsbxmdLykVqWyc?= =?us-ascii?Q?mETiTAFZvXllZuI2XVnXa7Bv3VGdY1lxGD9tRxKyHUtuyUD5d+fyrW/tpkV6?= =?us-ascii?Q?8q0qSAiyGUxFvVcWII/G4PSTb57jan+wigQYKVhuLI+wyLjU7CauqrnKrYz5?= =?us-ascii?Q?gWM1Zv9v7Xvdd+PYx28Zbqx5lTn5MsoFXWMgTEIXcmhjS3OmGNv1pNVLNDVy?= =?us-ascii?Q?E+fvWHbe5tcBNYi9DamqbhqnhRVdpSF/6mhNsPOPMTlGsEWMzjPGb62AcnFf?= =?us-ascii?Q?4tWJ3+lYQHqww2KBMxFNOdNPdoy9xGanYDvZkzCUgYbveCtD++GJk/79yX4R?= =?us-ascii?Q?gvZrv32IgtJJSrCSXLBqWsI0AszRWcmDXk5UN6F8b448sAPlIXEglu8iCH83?= =?us-ascii?Q?kMNpLIElPGrxXagQfX+mQHr/lIP1vmO4sFtXyuNOD+7yhKyT2qysh9fzUh6g?= =?us-ascii?Q?K9Nk9I81DdgBqWQCCCD8D6RxL0MxkdWvIR7bCVgo5skb/z7s07YMpOCcXXUI?= =?us-ascii?Q?RFifqxzVN30GsvaTSGAVSmVOnQEJJNbwmVay4H6QkRtF8DMp216DaWJfY5WY?= =?us-ascii?Q?ky6u4zC7py37lTzNVmGuyrgDjFN/Z73itO88jZrXF7wM//XXhNtdU51vwgzY?= =?us-ascii?Q?fzSgAtONLvE6n2iYEYtNfcF1jM5logd1cNB74J7UuFJO9cuWuyepRHiwcfcu?= =?us-ascii?Q?xFpCu80LlGpCSir7DnVlgNL+XYJttX+ocsd2Mi/F27zcnJgUqn2rV+AKoGiH?= =?us-ascii?Q?7G3eL2jyS+xpoG6H+DVYYOgTHLFSp20Hfn16rVUZyAjQSF9F3FhDjNHKdrnv?= =?us-ascii?Q?DvfgsCyzy/1SPTMgCzcuJ6EIg7kJlg5RCsaMYUoCsGsAts2kLixunM/I/5lc?= =?us-ascii?Q?VWQLVgQesKQjK2nCDopZcTXATZQ4CRwXdp6p0h3PKpv7FghwihpGNfs/jS00?= =?us-ascii?Q?7v3WaWjfD15QBgmg+VJbHTPsp6rJF2MN67gsvTKc2Z/eKeJqgjAnEjoLPb8q?= =?us-ascii?Q?BqGEu+2oYqqeUaivQEu69PLHXX0pcsdGY5OTkvqCri6sVVwOjw2bVZ3BiI65?= =?us-ascii?Q?pemhuvIJuNsHs5N4hZ89nVXNpgiYxDv/DEZA9dJiAEw/RMdVX8ZOZboVaZMz?= =?us-ascii?Q?wHkNtQgSZDh5vU4b3Xg3XjDorGBAHukDFE0AIn4H5MrxfQmjDJuqEwW5GEPu?= =?us-ascii?Q?rvQs8ctFEc0asviae0/2MGXrjqesvkjkff6yHlTIuyCcUUDXZM12n7fcZi69?= =?us-ascii?Q?lEfMD5QyHLfubjNf0HUy2zNH1p/iwqOXTsHZ/dFwLQWugfEtjqfnh6zLZPT/?= =?us-ascii?Q?8JWNgB8=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR11MB5678.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fTUKp1FLCtv3UxZqP7Y94ZUH9iJ2i5zhQBBa6vrMhkX5xRLBM+GO0eOIrwMb?= =?us-ascii?Q?SP4dDGeEprimlQpv9QHavF/9Uxt7Y1sOlmdZpZ4PmiobJ+e0ts8hmrTFDpvQ?= =?us-ascii?Q?ylKrfx8oZ3Jt0tw5S5RlK3HYcKdt9Q7Wt9qZsQz4mJ3SjeNzob7oPhx5iFvw?= =?us-ascii?Q?G9cNcIKu7RUeTnvvvn9aNY7XDx43uUyHquNe6i6WW/Xa0GquZ7LuAjSkJ4h8?= =?us-ascii?Q?bBjE0hx8ADSM+nz6nFc1ui2Kzfgh3PS8QVW8uJvv5X0r3CYM4ge28YpTKLFP?= =?us-ascii?Q?yMXcrA7TTyxxO9fcfM+ymRrr7trbmtdFlkPgpAdHGj8Mk0Z/aaN4IjeWUWZE?= =?us-ascii?Q?P5y/yMbgqZGlnGbY2Q/jmZKjoEHN2Y/J5Rdwy7N22pvLfCBluDU72FagVXm9?= =?us-ascii?Q?knEvp2MJ0TwzL66ah+M76jn24jLiT7dg9jQS5CW2MOhDznrwCjbYJb6smtB9?= =?us-ascii?Q?n0upyI+7H1rECENFEh4YadkPXOFULhehUbsrF8m7c6/vDx2rxsH1TApHrFzm?= =?us-ascii?Q?csKJHE0UbMc1ij+HdyTZZYOTR7MOUVPDhiKZtcsrXtyhQHaaYsge7x1YY9SY?= =?us-ascii?Q?neLnM+bWOM5LBqIzyoJENxIO5NzZHQATIw/c395v1NNXanS08JBUt+nj/vuL?= =?us-ascii?Q?GwRryv2wif1uX5E7AYpNpIeb8CjUbgWYmbtacV2UXOoVo6bmLWKErMCCZt98?= =?us-ascii?Q?8WCAVUfFa1R5bfJRWptxyCh1QzUWwkGf2dhzIm4CXp5x6JvR2O5Vj+0QztFw?= =?us-ascii?Q?Nm2RbI19NFkrSW6ZdW7GUW1xm2eTihWCEW4JXyXzc9UOHxaSGIIANrd2vOq4?= =?us-ascii?Q?jRbXZTxl8Zd97vJ2quS6WiWMC6eJ/8wu1fB/oe5yBr2fNoMw9y4I3s5cGu6B?= =?us-ascii?Q?qtRFaXL4VDo/7rVglQCAcyqUrzFdjaXJI2YUAMTeYZRciGyC6rrpZr1bEJLu?= =?us-ascii?Q?X/WuKK29+9OVGEitk/51qCN1X/rBVst7XX3heRwTWRvJc7LMx6/PakOMGTsr?= =?us-ascii?Q?aDXGthqLjKKQu+0U/Oiyl4qlMksEUMzV+RqBlPa8jKOxQ2o+arSnYtbsa9t6?= =?us-ascii?Q?zViBFMrWESybRcSd+RNfFxAXP6Cpi/r3n55p0dA4FNRU1IeHvu/UyvuXvUSG?= =?us-ascii?Q?ZEoLG2L3vr0FCS3vswuYHyZtKUDxfsgouAPXfDk5u2kHZHoZIaRJOSmerCek?= =?us-ascii?Q?oI878P/u0kDr0dHyoUsK+RJpEzsINs0VEzD1qJCNDBUIJVlezA7UjVNK7kgB?= =?us-ascii?Q?YwcCtbeS5U+fJwyHBFgryeB8/uBbm1zZZu1SIs0hg4zKIesWkTga2atKEXOP?= =?us-ascii?Q?wLlloTkBCFWtNUwnY9bEFfF5cCdjXLm3ZK3hCsFPOr+weIe65VkbdAdbMQW1?= =?us-ascii?Q?PV9IGzIyB7cm7+Ay4KuATopcpf5moldTreoEQWqAgtbHZHOEzN7LG8zfv7Kb?= =?us-ascii?Q?549f5017VXTClHxtCmK1hhcnhYdVqImZwfOp2gC9MOxFdYfZw1v2vZR4hJVU?= =?us-ascii?Q?aJMqrSoKDbYSOs3Ps0UU3DRfoht6wqVFM/uiuOxMJWOGY+/Ar1dXu4x5ahaN?= =?us-ascii?Q?WC60P9qJpaw/gKl7EPrYSLtYyOG83nG/Dv5AEiAXhm373bPfsqLQw5pv/T8R?= =?us-ascii?Q?sg=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: SJ0PR11MB5678.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26b6a723-4023-439e-b828-08dcff7a7805 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2024 22:21:04.4146 (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: VoRplsYoRNUQLYSDs7ozxDcnecxxwkiVEoflqPcxuFJZ1jl89o/Ta5YyrZl0q0dD1ednXnPeiBqtBCNxVKIenMDwnDUloW3SQiU6J+io9As= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4525 X-OriginatorOrg: intel.com X-Stat-Signature: mg3cbk7ew1qxbpw9nif4f6kz9xa1b3b8 X-Rspam-User: X-Rspamd-Queue-Id: 42329C0014 X-Rspamd-Server: rspam02 X-HE-Tag: 1731018058-929 X-HE-Meta: U2FsdGVkX19bM0V/QfsVhw36lTYZjlru2pen2W9dK2ImQYcDQsU50QCXSQQ5YzUlaOimlc7CyEjV30Oocc16YrBCJffKQjgnBPQiA1h9RsWVaFOEKtpQTRkZYgj8woOTAtL3M3+G3zk4M6+FmkzWoWYFrcjrj+J2SIcfQorjY7L3jevPKGLyScePpS4cVplTvk0fK2DEWYNTNilZ84hYZdiHpIy9Y2cypNMDfqfe3Ft0RieBIJ3gejLxQ4AMWnFY1e57sHIwCAdZHrKrzq6vY1bAvLWOcA1iHeJ/wmGzm97P3EYXPg2Y8CL8g3KI/2hsU4SHwCHyrfE2Q7uhMFFnj9pQzjMHlTCIyU4FML6x3Wx6Nufuu/PWOfynGg0F3ZuFU/05fp7xTE823QRMfvZARh+Fohssrl7jC9iXQRRDnT459MD5QQjcSl2ZpDSLNlNFbLSeYRNvh0OunMwrUwzOGH5LJWRifl2p3iq1vvoOZ0sS0vCaMOErGVe7bi5hPBLfD7KDFNXwya0PeegAJH4jPMqy6wXbW+kI7v1yg5DdRlAjDX+F3e3lsPCWo1Sw2hwcZY2RNyr42cZPncQRQXmtz/S8U/VPv8AibNayTktk9gKiygzROGWHTVof79+2pWtabAxYVql08zTpTKkGgz4OECHFyENCvGBTFZEx/pS9aX9RqOyRjVhrE7kQcfT9VWaYdbDKkw0A8YlWAbCjU9bx/PNEB3mpsW5cZG9kXnJrO8vScTF4HiKt0MzPUtsY69W+uGhE3EaDiWYJOOY88ozc+7oug3WO1oiBdJZwM+wHxvpNvXoCU3R0T9ECEnV/qVCISCD/OVZUuFxHFvo3RaMp+W5aXZFsY+Qxfw4iemPBoj+5GsDt80jUCyrW7JhdNttSTgzvVZQOkHH1NDoFBjJk0d4wPodHBqlMLQiBdfwM2voMucwszB8PMVr6jbpYDDudmwQ4qXnn4lNxKF9ngjl eWVmg4cB racn7ECqqFbOwHIx7mqVsoFob/018shE6y8IBE4JBWx/jlA3fW2NyedQ4Ga4XNna8npoh6+CnGFBplayRzLoBZQkGZFjTe1QlS6W4QgvtP/LHogzg/T+jKPMQ3SGXMbiY7vd2SKHFc0DB7GkK8YoqhFcoUS9kYglBeaspWvqlKTcPIEIl7MuYZR1jupzxrT8/hh5NAc8OOGPxEgRw05JxCjEKscrCOoiEjvxpoz9xObOn0EfaP5DwFn1D+jGqt3slm3p0i2Ngp1TzKnSfnx0wGMF6mxhOy8N1e1ju7ebXZ4J3rGcCpm9mfs6hwqRQt9ZJxd9aUuzOlBprnJV/onO+MOhj3YD0/4+ZMYaaA+P1oXAkhy9fyYY1vdvpUqvJXsJbVUAq08W/bz5gqHiDjTnFb0g9+dvFRTIaWIdU5mQpUJndgXV/GmL8UiDHJHCvJjyNctQk13npqadRF4+zJdcDwigxqNoC/mzmt8OW5fDBSJr+4LFeMFELnDYy9en1mm0kLdJP9oxcAw6O5CioWq6+UUPhcQ4fARU9dCz9PDUqMs5FWMibOt66m/mWkqoQGzu3QGfJ7ACmtXw6P3C6pHNBTIQj77+q7nPLyhW1cxN62dDd/CpKgcsPlX6o4ITAL1ESg5JX1/NGlCJov8OW3zUWkFLEu37c8/UdAFWdyYnz6STYmxHvOADdyQeq98b+AhAkOq6Q1q90FLd93CGZyXEoGKxLa2XSFGI7QI1LChDYzO5DZlAA+159ewp6dob9sWM+RuBkAXLq/bmgarqdrikP1mwEOmWa0bNbqiN6bGOgUyOrglcMU5XgpRzzOOMNdsFLvip/JtGBfEgAccxOIefyHDJ5/o7s/SEqAQNzOKrdyMPZfTRrhIJ1JcQv25bjGuDkMKgxQrI28gyeOjd5D+zBut59M3mQwNhY6EapYxH97hFRX2YgIVGzJmIsD7ZzjEk26p8zjDqWHgAsyBMmYFwWh0+b8d2M op6083xg gAWKGGCMACLMOzDleoDIhiwF5Y0BXNkoiHfFbxBPpP5BRUxgghIGLTo7wmBAivWr 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: Hi Johannes, > -----Original Message----- > From: Johannes Weiner > Sent: Thursday, November 7, 2024 9:21 AM > To: Sridhar, Kanchana P > Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org; > yosryahmed@google.com; nphamcs@gmail.com; > chengming.zhou@linux.dev; usamaarif642@gmail.com; > ryan.roberts@arm.com; Huang, Ying ; > 21cnbao@gmail.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 > ; zanussi@kernel.org; Feghali, Wajdi K > ; Gopal, Vinodh > Subject: Re: [PATCH v3 09/13] mm: zswap: Modify struct crypto_acomp_ctx > to be configurable in nr of acomp_reqs. >=20 > On Wed, Nov 06, 2024 at 11:21:01AM -0800, Kanchana P Sridhar wrote: > > Modified the definition of "struct crypto_acomp_ctx" to represent a > > configurable number of acomp_reqs and the required number of buffers. > > > > Accordingly, refactored the code that allocates/deallocates the acomp_c= tx > > resources, so that it can be called to create a regular acomp_ctx with > > exactly one acomp_req/buffer, for use in the the existing non-batching > > zswap_store(), as well as to create a separate "batching acomp_ctx" wit= h > > multiple acomp_reqs/buffers for IAA compress batching. > > > > Signed-off-by: Kanchana P Sridhar > > --- > > mm/zswap.c | 149 ++++++++++++++++++++++++++++++++++++++---------- > ----- > > 1 file changed, 107 insertions(+), 42 deletions(-) > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > index 3e899fa61445..02e031122fdf 100644 > > --- a/mm/zswap.c > > +++ b/mm/zswap.c > > @@ -143,9 +143,10 @@ bool zswap_never_enabled(void) > > > > struct crypto_acomp_ctx { > > struct crypto_acomp *acomp; > > - struct acomp_req *req; > > + struct acomp_req **reqs; > > + u8 **buffers; > > + unsigned int nr_reqs; > > struct crypto_wait wait; > > - u8 *buffer; > > struct mutex mutex; > > bool is_sleepable; > > }; > > @@ -241,6 +242,11 @@ static inline struct xarray > *swap_zswap_tree(swp_entry_t swp) > > pr_debug("%s pool %s/%s\n", msg, (p)->tfm_name, \ > > zpool_get_type((p)->zpool)) > > > > +static int zswap_create_acomp_ctx(unsigned int cpu, > > + struct crypto_acomp_ctx *acomp_ctx, > > + char *tfm_name, > > + unsigned int nr_reqs); >=20 > This looks unnecessary. Thanks for the code review comments. I will make sure to avoid the forward declarations. >=20 > > + > > /********************************* > > * pool functions > > **********************************/ > > @@ -813,69 +819,128 @@ static void zswap_entry_free(struct > zswap_entry *entry) > > /********************************* > > * compressed storage functions > > **********************************/ > > -static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node > *node) > > +static int zswap_create_acomp_ctx(unsigned int cpu, > > + struct crypto_acomp_ctx *acomp_ctx, > > + char *tfm_name, > > + unsigned int nr_reqs) > > { > > - struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > node); > > - struct crypto_acomp_ctx *acomp_ctx =3D per_cpu_ptr(pool- > >acomp_ctx, cpu); > > struct crypto_acomp *acomp; > > - struct acomp_req *req; > > - int ret; > > + int ret =3D -ENOMEM; > > + int i, j; > > > > + acomp_ctx->nr_reqs =3D 0; > > mutex_init(&acomp_ctx->mutex); > > > > - acomp_ctx->buffer =3D kmalloc_node(PAGE_SIZE * 2, GFP_KERNEL, > cpu_to_node(cpu)); > > - if (!acomp_ctx->buffer) > > - return -ENOMEM; > > - > > - acomp =3D crypto_alloc_acomp_node(pool->tfm_name, 0, 0, > cpu_to_node(cpu)); > > + acomp =3D crypto_alloc_acomp_node(tfm_name, 0, 0, > cpu_to_node(cpu)); > > if (IS_ERR(acomp)) { > > pr_err("could not alloc crypto acomp %s : %ld\n", > > - pool->tfm_name, PTR_ERR(acomp)); > > - ret =3D PTR_ERR(acomp); > > - goto acomp_fail; > > + tfm_name, PTR_ERR(acomp)); > > + return PTR_ERR(acomp); > > } > > + > > acomp_ctx->acomp =3D acomp; > > acomp_ctx->is_sleepable =3D acomp_is_async(acomp); > > > > - req =3D acomp_request_alloc(acomp_ctx->acomp); > > - if (!req) { > > - pr_err("could not alloc crypto acomp_request %s\n", > > - pool->tfm_name); > > - ret =3D -ENOMEM; > > + acomp_ctx->buffers =3D kmalloc_node(nr_reqs * sizeof(u8 *), > > + GFP_KERNEL, cpu_to_node(cpu)); > > + if (!acomp_ctx->buffers) > > + goto buf_fail; > > + > > + for (i =3D 0; i < nr_reqs; ++i) { > > + acomp_ctx->buffers[i] =3D kmalloc_node(PAGE_SIZE * 2, > > + GFP_KERNEL, > cpu_to_node(cpu)); > > + if (!acomp_ctx->buffers[i]) { > > + for (j =3D 0; j < i; ++j) > > + kfree(acomp_ctx->buffers[j]); > > + kfree(acomp_ctx->buffers); > > + ret =3D -ENOMEM; > > + goto buf_fail; > > + } > > + } > > + > > + acomp_ctx->reqs =3D kmalloc_node(nr_reqs * sizeof(struct acomp_req > *), > > + GFP_KERNEL, cpu_to_node(cpu)); > > + if (!acomp_ctx->reqs) > > goto req_fail; > > + > > + for (i =3D 0; i < nr_reqs; ++i) { > > + acomp_ctx->reqs[i] =3D acomp_request_alloc(acomp_ctx- > >acomp); > > + if (!acomp_ctx->reqs[i]) { > > + pr_err("could not alloc crypto acomp_request > reqs[%d] %s\n", > > + i, tfm_name); > > + for (j =3D 0; j < i; ++j) > > + acomp_request_free(acomp_ctx->reqs[j]); > > + kfree(acomp_ctx->reqs); > > + ret =3D -ENOMEM; > > + goto req_fail; > > + } > > } > > - acomp_ctx->req =3D req; > > > > + /* > > + * The crypto_wait is used only in fully synchronous, i.e., with scom= p > > + * or non-poll mode of acomp, hence there is only one "wait" per > > + * acomp_ctx, with callback set to reqs[0], under the assumption that > > + * there is at least 1 request per acomp_ctx. > > + */ > > crypto_init_wait(&acomp_ctx->wait); > > /* > > * if the backend of acomp is async zip, crypto_req_done() will > wakeup > > * crypto_wait_req(); if the backend of acomp is scomp, the callback > > * won't be called, crypto_wait_req() will return without blocking. > > */ > > - acomp_request_set_callback(req, > CRYPTO_TFM_REQ_MAY_BACKLOG, > > + acomp_request_set_callback(acomp_ctx->reqs[0], > CRYPTO_TFM_REQ_MAY_BACKLOG, > > crypto_req_done, &acomp_ctx->wait); > > > > + acomp_ctx->nr_reqs =3D nr_reqs; > > return 0; > > > > req_fail: > > + for (i =3D 0; i < nr_reqs; ++i) > > + kfree(acomp_ctx->buffers[i]); > > + kfree(acomp_ctx->buffers); > > +buf_fail: > > crypto_free_acomp(acomp_ctx->acomp); > > -acomp_fail: > > - kfree(acomp_ctx->buffer); > > return ret; > > } > > > > -static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node > *node) > > +static void zswap_delete_acomp_ctx(struct crypto_acomp_ctx > *acomp_ctx) > > { > > - struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > node); > > - struct crypto_acomp_ctx *acomp_ctx =3D per_cpu_ptr(pool- > >acomp_ctx, cpu); > > - > > if (!IS_ERR_OR_NULL(acomp_ctx)) { > > - if (!IS_ERR_OR_NULL(acomp_ctx->req)) > > - acomp_request_free(acomp_ctx->req); > > + int i; > > + > > + for (i =3D 0; i < acomp_ctx->nr_reqs; ++i) > > + if (!IS_ERR_OR_NULL(acomp_ctx->reqs[i])) > > + acomp_request_free(acomp_ctx->reqs[i]); > > + kfree(acomp_ctx->reqs); > > + > > + for (i =3D 0; i < acomp_ctx->nr_reqs; ++i) > > + kfree(acomp_ctx->buffers[i]); > > + kfree(acomp_ctx->buffers); > > + > > if (!IS_ERR_OR_NULL(acomp_ctx->acomp)) > > crypto_free_acomp(acomp_ctx->acomp); > > - kfree(acomp_ctx->buffer); > > + > > + acomp_ctx->nr_reqs =3D 0; > > + acomp_ctx =3D NULL; > > } > > +} > > + > > +static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node > *node) > > +{ > > + struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > node); > > + struct crypto_acomp_ctx *acomp_ctx; > > + > > + acomp_ctx =3D per_cpu_ptr(pool->acomp_ctx, cpu); > > + return zswap_create_acomp_ctx(cpu, acomp_ctx, pool->tfm_name, > 1); > > +} > > + > > +static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node > *node) > > +{ > > + struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > node); > > + struct crypto_acomp_ctx *acomp_ctx; > > + > > + acomp_ctx =3D per_cpu_ptr(pool->acomp_ctx, cpu); > > + zswap_delete_acomp_ctx(acomp_ctx); > > > > return 0; > > } >=20 > There are no other callers to these functions. Just do the work > directly in the cpu callbacks here like it used to be. There will be other callers to zswap_create_acomp_ctx() and zswap_delete_acomp_ctx() in patches 10 and 11 of this series, when the per-cpu "acomp_batch_ctx" is introduced in struct zswap_pool. I was trying to modularize the code first, so as to split the changes into smaller commi= ts. The per-cpu "acomp_batch_ctx" resources are allocated in patch 11 in the "zswap_pool_can_batch()" function, that allocates batching resources for this cpu. This was to address Yosry's earlier comment about minimizing the memory footprint cost of batching. The way I decided to do this is by reusing the code that allocates the de-f= acto pool->acomp_ctx for the selected compressor for all cpu's in zswap_pool_cre= ate(). However, I did not want to add the acomp_batch_ctx multiple reqs/buffers allocation to the cpuhp_state_add_instance() code path which would incur th= e memory cost on all cpu's. Instead, the approach I chose to follow is to allocate the batching resourc= es in patch 11 only as needed, on "a given cpu" that has to store a large foli= o. Hope this explains the purpose of the modularization better. Other ideas towards accomplishing this are very welcome. Thanks, Kanchana >=20 > Otherwise it looks good to me.