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 5F32ED5D699 for ; Thu, 7 Nov 2024 22:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C41FD6B00A6; Thu, 7 Nov 2024 17:50:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF1DA6B00A7; Thu, 7 Nov 2024 17:50:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F6596B00A8; Thu, 7 Nov 2024 17:50:45 -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 7974F6B00A6 for ; Thu, 7 Nov 2024 17:50:45 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 19E10120159 for ; Thu, 7 Nov 2024 22:50:45 +0000 (UTC) X-FDA: 82760794830.02.B6760E6 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by imf12.hostedemail.com (Postfix) with ESMTP id B460A4001B for ; Thu, 7 Nov 2024 22:50:24 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PbbKrD+k; dmarc=pass (policy=none) header.from=intel.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf12.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1731019716; a=rsa-sha256; cv=pass; b=CByVSLSDdyKhhcRP7Kq4Z3HrJ8Pn15fmJmu8Z9A+rE+YsO9ZW12pNDus7lM4p3wE+4q3rB sx3K/hHdcFzElZGAbNSzoHXRKLwZvkDk394QwRD78t3eljK32Mf2C9PUmdaoLxUPn7ucvj 51JFGjGrqOLZCTPmOILJn3yhFkb47xs= ARC-Authentication-Results: i=2; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PbbKrD+k; dmarc=pass (policy=none) header.from=intel.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf12.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731019716; 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=yzy4OZ1qPg6MqQDx+mMe3EKe8898CczU3yzwfjxMvoA=; b=ytfsvcEzY0IBbx2wJV8JoCwPIM0TNfu9GZZCkJXmRBBhBLS57H9YUovXAbEFnAgcG5Iblf O7Py3oJpjApFsoa8ju3h0AGmUEIWbJde5jDGBRbdecS33fGfp1oSgOIKAOoUuxaYAQg+/+ nIi65RYqWuETP2PUATM27hpvqrCfk9w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1731019841; x=1762555841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xIjrekqteTeTWXeZZ3FinwRvTlENDQDnO+5tRJSeSvQ=; b=PbbKrD+kUtIUjY82fIeBJrlGKyRC91ZWoZJcPf1SupIZuhDs9QVCIKv2 blkLan5Q1Vu6hd8CclZD788LJx206NNuZFnfBETsIrlVnQmRqHOe7ciZi s8hCTfV7MH0joPRV5o4v6cYSBsZ1AnwHPSmFGBu1/IWBYDbqoDx5gRb2l 6O7dlD7G9v33pvHybsvH9RvtoYoYOl0vV2euomWhMjEKxHr/bxNP7yVCL QcxAMFLqpt4zh1DCp78CcwE/NMuUhEpUub1Em//L2hqBhExztbLKOmQD5 +jQQXzhcV8A0dsTQgf4lCQsCWDLPxMXEX94jDQa09WkbKN56Jx5/3l7bw w==; X-CSE-ConnectionGUID: 5R6LnHZxRSqyk1X1nXEVBA== X-CSE-MsgGUID: 1QRY4moST+m2sxy3qwdKCA== X-IronPort-AV: E=McAfee;i="6700,10204,11249"; a="42265191" X-IronPort-AV: E=Sophos;i="6.12,136,1728975600"; d="scan'208";a="42265191" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2024 14:50:39 -0800 X-CSE-ConnectionGUID: wQ0w7/OmRCOsKxLFzYVyvQ== X-CSE-MsgGUID: gUT3gvyAR3yQR135Pgfh9w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,136,1728975600"; d="scan'208";a="116124295" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orviesa002.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 07 Nov 2024 14:50:39 -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:50:37 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) 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:50:37 -0800 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.170) by edgegateway.intel.com (192.55.55.70) 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:50:37 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WeCHbyFNrWDNt9WG7ic0dLCJLI6pE2vE1CJu0NhRLl9A1vOELd2QFDisx4gM8G1t4EEK83MiklrkO0zQePUOOSuDZVOIv2YHgLrs21bDVeE5r6sVqIrmyHM0izlwurZkBUHyyCbNzGBZ09xwtPJYgsJrzNuOZddWnfZTzFb4mj1EVBD/r6KBfb+LKyPqL3IwEIbFyoUePtfxCAbqqcd9YS+pOt2iJdRCxRBovZnvP1cCE1dOrOv1IH6KwVsBnkClCK/uQChhWlty6rerDxBg51FwiJWPUJ4ai2LaDtye4ssV6pz/lq60CwCGCN4izMRzVi9/UGt1EP9O2T7DgVJczQ== 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=yzy4OZ1qPg6MqQDx+mMe3EKe8898CczU3yzwfjxMvoA=; b=ON9mfgR8CrS2/eLMI+rXd6YKJC4rWYXU+RPc8oSiE4L0l2zmHdNtWynmsUubzDPFj6aIiGD4dUEHT0vUTLMXAhsKX6r8Is2l3z3dpbq+HNq1AaGUuH3ijflh4cBvw7342ukaaDcmwW5DEkAJovPkby7cxEebFJl8dfYctNRE3+sByT62TmQb1KV3PcfkSprXCXkfa/dNrqrMtkxVCuBZU5OcWKyEUMcotUhTRu76bKB4W9myIvQbdysEWOLOK7BGWFRATAFEu9c0CVpHQyGtHZDNlbHKmQGtYxhzKBinjKYOiD6hB1b16umT82rOoxWdMNYqz/5KybPYel6yLn3PXQ== 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 SJ2PR11MB8401.namprd11.prod.outlook.com (2603:10b6:a03:539::19) 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:50:34 +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:50:34 +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 13/13] mm: zswap: Compress batching with Intel IAA in zswap_store() of large folios. Thread-Topic: [PATCH v3 13/13] mm: zswap: Compress batching with Intel IAA in zswap_store() of large folios. Thread-Index: AQHbMIESeDDekiFHHEqRnEEQm8zAvbKsK7YAgAA9ZfA= Date: Thu, 7 Nov 2024 22:50:34 +0000 Message-ID: References: <20241106192105.6731-1-kanchana.p.sridhar@intel.com> <20241106192105.6731-14-kanchana.p.sridhar@intel.com> <20241107185340.GG1172372@cmpxchg.org> In-Reply-To: <20241107185340.GG1172372@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_|SJ2PR11MB8401:EE_ x-ms-office365-filtering-correlation-id: 0f3cccf9-b150-48fd-1cec-08dcff7e96e7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?VxqR4Pc2PS++YQHRYwgnG6/inICAvyn/HubX45NJICxMJcHwQorG+GqnUIrK?= =?us-ascii?Q?Neh3E2gOw+MGRJZBQMXcfuGGP0y4FlxU9jUs6mQMvpbzk/Mg86KTiDM85v+x?= =?us-ascii?Q?bikPi47IFFU3Ns8zCs0NFTKM3z8+O5h30WhqJKV/NGNW/40OrfQKB+cJP+FI?= =?us-ascii?Q?agrYB2Z8LIbeXPYyfCQfX8Yy0y4sN8wKX8annkb89x2ZpbXNywMGFO3wkR6d?= =?us-ascii?Q?4ZbUgH4Eh6U3ylLxb9tl16m2dPQcKfUlBa+KLfNo0yKa7g6YAAZ3oz0418iG?= =?us-ascii?Q?WndlEda0XRW5E14+2FaBV7UdNB6nJeugliROD7N47xE5HbbWnJqAnYPyAF85?= =?us-ascii?Q?0tWo+WRnQ7BCFpD62ySiU/BZKMArtB4KswZbAMhviikZ1nfbXGXJoOlbLgoC?= =?us-ascii?Q?0YZnY7XrMKmFBRr+33szexN0g8tTWx+R0G7z9j8kNB8TPkctsxQ09SGQwGRt?= =?us-ascii?Q?6MTKlhC3Ypkg4TO6Mxx+ntgfd+1F+YPHyYwLtqLbqUPH4H3SB7/ujDpxDZgf?= =?us-ascii?Q?tdUmpD5UZiOXsgd4XukOcfkV5/qMGUfhw1jadvYB62UEzk5Yc097xSzhIkhX?= =?us-ascii?Q?JdrGRIzjobJVspmeA2AaMSr7lkXb4cN2eU/V4PdgESsDMcxPI9kh8aOiZNmj?= =?us-ascii?Q?dPyNT4kf9E7GnQoApnCTdxT5aoLRkuzNliqprYQCMpflpHmNCxCENU7LEuIW?= =?us-ascii?Q?J6BtUXwVrqMraHloD7tDEzGMpjvb12nq1Qug/9NM1qDq2ZClyHCjCqGZ7VZj?= =?us-ascii?Q?ha7C7fEAxG2X8ptmDvegJ82p3+aLAdoxdAQH7YUukxaOBlhD0SnZItgURJtL?= =?us-ascii?Q?IiYAU4hgu5UA+0BRRHxSCFuecK75c2Mjm4advIjw9XYx04f5dndxhyDPtcM6?= =?us-ascii?Q?XE1kZjxGEjDY9IQsYxdpifK9AWO8wy8IBvveBZ9DNEiBXZ0T7VhbojUOG91g?= =?us-ascii?Q?3epY2F//8eXRu7yWTAO4ITT0kagkI9ULmjzWcH/66ln5s85reVyn582Ld0+f?= =?us-ascii?Q?SZSOjs94QTRUaa6gsBzILdxI70zbH+QGc2YmvOlwPIL/+Sj6CLEO+my/H5/3?= =?us-ascii?Q?oVsa/AUNVVzF9E3jvNwijw+ViZUv9augk7Udfv40LUW8fsn+K7gfZA7Y0IXM?= =?us-ascii?Q?17ZrILOQSu/k0i4fipHBLUb8Hic88qHVx67lWivyzGILzOjDohELzEUTsicO?= =?us-ascii?Q?4IAGQL78o8iLcRooIlJcg1mNzcllhXHeufJwSV4zbJEIb+PvNx2C3m6rfNj9?= =?us-ascii?Q?pu8svLP+wr9Go7bjQfhOYhEBDmqPYp09B83p0KJLhS8WE5I3fcCog4D434Ln?= =?us-ascii?Q?eX/RxqCxqF9m2FZccSBKkTrkSlh0iaKAaaxnO1MVgZp01EOeJLfdd84fDp3q?= =?us-ascii?Q?wg0UT68=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)(366016)(1800799024)(376014)(7416014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?N1+KWuAUxYsZmJPjkR0Cj+nmHEEOoZ7cXeIuHTEcPIk4SNJ9aJR2VXXqUNd+?= =?us-ascii?Q?IwL9SmegR7iKK/M+AraiI9Ea0BSq4HBVgeJTbJfdAtaUDIXBa6ulc+VcuAMd?= =?us-ascii?Q?LJO8adBxV/j9S5zfYgv/5dgLFc8BDEcWFqN++Dvw9Dw3CDeBd5+FyJpYUHEy?= =?us-ascii?Q?hiBiPwxGdX1W8URMleCo6IfnCIopRYS8r9jcyR/hI9gLAGGDBu/LNg5WzLDe?= =?us-ascii?Q?Eq1AF7uZ8lm6PGDdwE2NA3aSgS9LX6tl6plBjIvu9XQ1m/gg9nApn6HmZCPH?= =?us-ascii?Q?22ZSlR1g2NA9+X/lXELQxGMnbRgNi0rEZzxplmazFTz7SIw1EN/pK5RoDpQj?= =?us-ascii?Q?98nee8nPVyLWh4L6KacPACpKCsyAx+lE+A+behJa3K/GxqaDr5btNJf+nVvx?= =?us-ascii?Q?70eVSOYRmDm9OY68pbhq630ps5udrRPp2GJanbBMRYdnc/tMsdYxpUBsJyJ1?= =?us-ascii?Q?Qf/zbyLLXPzCxkXOtAe/ruoF/D5mu4vIVi3+H/9xA8cSb7hJHxoWR6YMhi8p?= =?us-ascii?Q?W1o+QtiAbfQmWBdlRKPGj+vXZxBPjPEwQzb8W8CmEygEbnje74JtNLBHakSj?= =?us-ascii?Q?ulY4UJbyotwX9o1xvzA81IA2QkF1hlDeHyYhtYk6HDQQE8JVKWv+SNMdTQPZ?= =?us-ascii?Q?qQifZKy6RH5tMH0gHlImfsHDlQrPGJk85x1HrMp/O8AWlrmE0D/Y+s6UyqIC?= =?us-ascii?Q?TI4Q3m90zcSvEY3kt91sldu++riQCNcHB6Q4tSZfSuZHf5jTTRN0/GHjQA83?= =?us-ascii?Q?Cs6BG6QxqLbjyhhvqikE1IVJ4iv+qurP/43ab7xRFsBM/7cNkA7wvcHEDu+L?= =?us-ascii?Q?+pb7T06oi5qp1yBFF6JytXgF0MOvLtkRadwn5pm8tDr3x7WF0Ov3wGneEQbm?= =?us-ascii?Q?75diR/zLV/V9VbQkCjCRq6I8sMKkyaDVVCBQ2KqcsnuDzEG5YYWBxcL6y7zP?= =?us-ascii?Q?YWG5Q/LGPRPgjjlihNOhiwhW42cdgK5JRqZtpAvcl2n6g3XWxtlGWTqkZRan?= =?us-ascii?Q?VsxzI1jCPagpF6EAsQ4sNmg6dsq0XXCiogkVaaxb/xxwo4QTiQex6qUtK3HE?= =?us-ascii?Q?bIh8JJp8OpAfcPPK5SHD5J8pfiIze6LlbIBquzeHtJkGW5DIpW74xP1GAY9y?= =?us-ascii?Q?nm2xtcuJjFrLxY7mZDzii5vg1vrdRv0xhugn7ZuHDG4oZOwRwauo1KC1Sh/y?= =?us-ascii?Q?xzfIkkBGejWVdzj56ukADO79I+ZbN6u3NovSDxZWqX2GZCW6RqA6xdWIdCaT?= =?us-ascii?Q?qBKE6j+xZUuWxA4tlR/Od9q1ZDZfdfzolzeLjeGBpaEOnquFvpu1kQI8BuX8?= =?us-ascii?Q?v9nC71R2J5N6v7hn3fVG/T71dps3zk0Rn0Pd7TPUghHeWbUdm+k8zLN5/JlR?= =?us-ascii?Q?FmX2uFlIpWMgOl/pAinttoNw6+C+NUO98fiyNFRPfKyUNIawBnbHvJNSpCyY?= =?us-ascii?Q?5AKqpaQ9iDYh11T+IyvQhzbrVK8vpMEIRYeMGiPAaOY/3Bxwl2tF4UeJjAdC?= =?us-ascii?Q?WQ8lop91YYoyNq1akVlxLlvZxiVaA3tLNU3heKGBdL+8jNPH/vFHVY/4K8yV?= =?us-ascii?Q?1mV6YixZnqK67b7OzMfQ2jvPW4gcdVXHFn0nnezhHquCN5OTt+D9Wzp9YZyq?= =?us-ascii?Q?bg=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: 0f3cccf9-b150-48fd-1cec-08dcff7e96e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2024 22:50:34.2126 (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: oBfnaC+Z3Nx5W3fsVBBIQParTrU6yJ69iIRWa3owmKPPiLuUNQbD01syhBoDn6R7X4FYA2nVnYsBfXeJ3EysxaNCLRD+c9a6uc/flCfTcMM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB8401 X-OriginatorOrg: intel.com X-Rspamd-Queue-Id: B460A4001B X-Stat-Signature: wk1zfkjpdhfp4wm1xcej1ygxsaajzz1z X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731019824-902465 X-HE-Meta: U2FsdGVkX1+sdEGy+MF7ZlOn5dRFxduo5uiapw+as2UrH2ul7RD/cS7Ahv8uqn+Edd03Yd3DcQAJBET3i0xvA0eS5WZlf9Jz0QfTMAuDGh+soKkPpK28JIGCQDGJwtuauPSrrJdvMLyzlR2WUcw+JQ0mxtKJene0pkPS06O4iwYJKYk6eDO9yLgnSojbVzV3YzU74q4DRWMNhAEVqpqoVpkde4/SIHlGhUlbsM85xMgYX6a+2rleJH+4RTQrgKujmMICJWK0RqwhOl/8X/J3BeFG2IOQcxTXZSNSq09MfxDYHYX2Dj3gMo4RuNX6Rt25CDNNwUgIx/hADWvjr9BIguz6elGlhDS7YrpCb853xeSSMOLRnuns/9nHrBi10Pe7YVnaQ8M1QjeEEqhdlRApk/VgXPX6vYTH8HssJ9MkWJ1T3TUaEqae3mHY4oYCc79L+ysRqSr9NgF85L/+UO79MomkaNSlpBCy/LSy799UDKHd6GJt6EqjF5ZRlQ6pD2tOTNYjr/hArA2ji1u7oIiZYl9NjxoNSvmTWL373ltFzImw3fmhGlVrm812njaO0SZGF8vVQLUnJOuoBh/4vCNtW+v6SQHqsztRoqcs79JDsIwf92KnykC2N18bW27wd5R9rw7oL6zdhmKSOBRN/LnDkqU4yMLehJmw+UOLvrsfFK6h2qWMpNMo90YkWo29ulY4TvaIPwao2B0mlqFwzflZaceio1M9TBQlNmazRQO3lEsTZ0iZOt2W8k4W8quEXHtfI0psypxsJOw14l5000kRGBaKiCj39XMDEiU/q4A+h415ZaRqrrOJDRs+jH+VIgxE38SHaz1Uu/GBJX2awrQ1uvxbK8N66eCR8HF252hu6dPUqZejOFmrxDBsehRume9kXqqR0Pxre0OnEeuTwe0LBlVXqKB5BRfrxBDeHq+4e3teCE7Bwj2QHhtydraIYSYG1zsj8Gr6O43SpumHPWK zznRObvB GWrv/OfSLa4DKw5JqKzyDseU1ylpAQzXoFsk6oQ4TkKPn2PIPX8DKXt1UBpEKNneA/6+inxU9xXM8Jaza7hq3VPxooOiY8HKLPp4zh/3LsXii/rUIFX0Y0kMmhs8ZZkIDdKf6+RV02J608xdIupW8ffK9CLkjq0dps70qR9guIsGV3k14zZ3ghN5bmIafOZe8WEbLxDmDpnAKeBZL2q9Axu4e9QjwyyDU33+bQduaBtA3gbPDZiJCPS/JNm8G0yFVaVkHCiXmg5Ja2jz42sbhXnb12V/Q/FuKncg/gt+SVfKBGGRIabJ96SXY+0cKgUxc01b39Ryzh9Q/1n6DwETgUKQDOrVBmkWmFYKo7OvUqqnUtmEnpFE7Q313gb5zkF3tI1VFJvcAQafK1yzqye9JbG9D+kUBiP2hBhXl9e+FCMS0fBU8tzISVLSrQFrw1zjJ4ntlSBLPG7zW0f8lgiLQW4rWO5VMqiwSxBMF6g2JnW7gR9fKjnRSsCl6oiZcRG2pwpV3QI5PUcdPNNo/WyGVCre4nQ7P1VtpXjreHfolLFuW4ehT4TNfdxY8jneIs6WwpaHNgCzSSWYhisgSOgIkZidNA4OSaSRK3aDXhQCnego+G451rqw7p/LIYM0AxK9k0jcmq2uJSJJIVVY2qpMwMULWFDXpICbG/V46xCTdU3+4EXDKVtiCJa7wkbAOI5bNESPdDQ7/pCfuMCwJ5u1Ls+ozF/KCO8vtCjxp+ZWBXFQAhTXO2Sxrc+odn9x5V9vSZ2sFsUcNOTKR8+g99enDdmZIPqTxaNUEuGl1K/pp8d3oW92NH+ItHHk/Ad2h74fZ/a6AYpaHKMwlFPSr7X7LA7o2UkqG1IJl/1yXVzIyChkC3Vu/dVq0AH1NLV8B7pP/g+1WvwCm6O5VMn+aaHD3IRnHCHum289CaUYSbXBDT8ZxJencpiKg3pjdt5ScGlF0vlglZtYkte9YRjrrLrxVHAP6vRjU 4pTeTbyb 7xzt6AKflFB05jsDPs6+wRfr+/v9T30MGXxoAp2KUijEbwm3xVlBANBbQfHnlMi5 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: Johannes Weiner > Sent: Thursday, November 7, 2024 10:54 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 13/13] mm: zswap: Compress batching with Intel IAA > in zswap_store() of large folios. >=20 > On Wed, Nov 06, 2024 at 11:21:05AM -0800, Kanchana P Sridhar wrote: > > +static void zswap_zpool_store_sub_batch( > > + struct zswap_store_pipeline_state *zst) >=20 > There is a zswap_store_sub_batch() below, which does something > completely different. Naming is hard, but please invest a bit more > time into this to make this readable. Thanks Johannes, for the comments. Yes, I agree the naming could be better. >=20 > > +{ > > + u8 i; > > + > > + for (i =3D 0; i < zst->nr_comp_pages; ++i) { > > + struct zswap_store_sub_batch_page *sbp =3D &zst- > >sub_batch[i]; > > + struct zpool *zpool; > > + unsigned long handle; > > + char *buf; > > + gfp_t gfp; > > + int err; > > + > > + /* Skip pages that had compress errors. */ > > + if (sbp->error) > > + continue; > > + > > + zpool =3D zst->pool->zpool; > > + gfp =3D __GFP_NORETRY | __GFP_NOWARN | > __GFP_KSWAPD_RECLAIM; > > + if (zpool_malloc_support_movable(zpool)) > > + gfp |=3D __GFP_HIGHMEM | __GFP_MOVABLE; > > + err =3D zpool_malloc(zpool, zst->comp_dlens[i], gfp, &handle); > > + > > + if (err) { > > + if (err =3D=3D -ENOSPC) > > + zswap_reject_compress_poor++; > > + else > > + zswap_reject_alloc_fail++; > > + > > + /* > > + * An error should be propagated to other pages of > the > > + * same folio in the sub-batch, and zpool resources for > > + * those pages (in sub-batch order prior to this zpool > > + * error) should be de-allocated. > > + */ > > + zswap_store_propagate_errors(zst, sbp->batch_idx); > > + continue; > > + } > > + > > + buf =3D zpool_map_handle(zpool, handle, ZPOOL_MM_WO); > > + memcpy(buf, zst->comp_dsts[i], zst->comp_dlens[i]); > > + zpool_unmap_handle(zpool, handle); > > + > > + sbp->entry->handle =3D handle; > > + sbp->entry->length =3D zst->comp_dlens[i]; > > + } > > +} > > + > > +/* > > + * Returns true if the entry was successfully > > + * stored in the xarray, and false otherwise. > > + */ > > +static bool zswap_store_entry(swp_entry_t page_swpentry, > > + struct zswap_entry *entry) > > +{ > > + struct zswap_entry *old =3D > xa_store(swap_zswap_tree(page_swpentry), > > + swp_offset(page_swpentry), > > + entry, GFP_KERNEL); > > + if (xa_is_err(old)) { > > + int err =3D xa_err(old); > > + > > + WARN_ONCE(err !=3D -ENOMEM, "unexpected xarray error: > %d\n", err); > > + zswap_reject_alloc_fail++; > > + return false; > > + } > > + > > + /* > > + * We may have had an existing entry that became stale when > > + * the folio was redirtied and now the new version is being > > + * swapped out. Get rid of the old. > > + */ > > + if (old) > > + zswap_entry_free(old); > > + > > + return true; > > +} > > + > > +static void zswap_batch_compress_post_proc( > > + struct zswap_store_pipeline_state *zst) > > +{ > > + int nr_objcg_pages =3D 0, nr_pages =3D 0; > > + struct obj_cgroup *objcg =3D NULL; > > + size_t compressed_bytes =3D 0; > > + u8 i; > > + > > + zswap_zpool_store_sub_batch(zst); > > + > > + for (i =3D 0; i < zst->nr_comp_pages; ++i) { > > + struct zswap_store_sub_batch_page *sbp =3D &zst- > >sub_batch[i]; > > + > > + if (sbp->error) > > + continue; > > + > > + if (!zswap_store_entry(sbp->swpentry, sbp->entry)) { > > + zswap_store_propagate_errors(zst, sbp->batch_idx); > > + continue; > > + } > > + > > + /* > > + * The entry is successfully compressed and stored in the tree, > > + * there is no further possibility of failure. Grab refs to the > > + * pool and objcg. These refs will be dropped by > > + * zswap_entry_free() when the entry is removed from the > tree. > > + */ > > + zswap_pool_get(zst->pool); > > + if (sbp->objcg) > > + obj_cgroup_get(sbp->objcg); > > + > > + /* > > + * We finish initializing the entry while it's already in xarray. > > + * This is safe because: > > + * > > + * 1. Concurrent stores and invalidations are excluded by folio > > + * lock. > > + * > > + * 2. Writeback is excluded by the entry not being on the LRU > yet. > > + * The publishing order matters to prevent writeback from > seeing > > + * an incoherent entry. > > + */ > > + sbp->entry->pool =3D zst->pool; > > + sbp->entry->swpentry =3D sbp->swpentry; > > + sbp->entry->objcg =3D sbp->objcg; > > + sbp->entry->referenced =3D true; > > + if (sbp->entry->length) { > > + INIT_LIST_HEAD(&sbp->entry->lru); > > + zswap_lru_add(&zswap_list_lru, sbp->entry); > > + } > > + > > + if (!objcg && sbp->objcg) { > > + objcg =3D sbp->objcg; > > + } else if (objcg && sbp->objcg && (objcg !=3D sbp->objcg)) { > > + obj_cgroup_charge_zswap(objcg, > compressed_bytes); > > + count_objcg_events(objcg, ZSWPOUT, > nr_objcg_pages); > > + compressed_bytes =3D 0; > > + nr_objcg_pages =3D 0; > > + objcg =3D sbp->objcg; > > + } > > + > > + if (sbp->objcg) { > > + compressed_bytes +=3D sbp->entry->length; > > + ++nr_objcg_pages; > > + } > > + > > + ++nr_pages; > > + } /* for sub-batch pages. */ > > + > > + if (objcg) { > > + obj_cgroup_charge_zswap(objcg, compressed_bytes); > > + count_objcg_events(objcg, ZSWPOUT, nr_objcg_pages); > > + } > > + > > + atomic_long_add(nr_pages, &zswap_stored_pages); > > + count_vm_events(ZSWPOUT, nr_pages); > > +} > > + > > +static void zswap_store_sub_batch(struct zswap_store_pipeline_state > *zst) > > +{ > > + u8 i; > > + > > + for (i =3D 0; i < zst->nr_comp_pages; ++i) { > > + zst->comp_dsts[i] =3D zst->acomp_ctx->buffers[i]; > > + zst->comp_dlens[i] =3D PAGE_SIZE; > > + } /* for sub-batch pages. */ > > + > > + /* > > + * Batch compress sub-batch "N". If IAA is the compressor, the > > + * hardware will compress multiple pages in parallel. > > + */ > > + zswap_compress_batch(zst); > > + > > + zswap_batch_compress_post_proc(zst); >=20 > The control flow here is a mess. Keep loops over the same batch at the > same function level. IOW, pull the nr_comp_pages loop out of > zswap_batch_compress_post_proc() and call the function from the loop. I see. Got it. >=20 > Also give it a more descriptive name. If that's hard to do, then > you're probably doing too many different things in it. Create > functions for a specific purpose, don't carve up sequences at > arbitrary points. >=20 > My impression after trying to read this is that the existing > zswap_store() sequence could be a subset of the batched store, where > you can reuse most code to get the pool, charge the cgroup, allocate > entries, store entries, bump the stats etc. for both cases. Alas, your > naming choices make it a bit difficult to be sure. Apologies for the naming choices. I will fix this. As I was trying to expla= in in the commit log, my goal was to minimize failure points, since each failu= re point requires unwinding state, which adds latency. Towards this goal, I tr= ied to alloc all entries upfront, and fail early to prevent unwinding state. Especially since the upfront work being done for the batch, is needed in any case (e.g. zswap_alloc_entries()). This is where the trade-offs between treating the existing zswap_store() sequence as a subset of the batched store are not very clear. I tried to optimize the batched store for batching, while following the logical structure of zswap_store(). >=20 > Please explore this direction. Don't worry about the CONFIG symbol for > now, we can still look at this later. Definitely, I will think some more about this. >=20 > Right now, it's basically >=20 > if (special case) > lots of duplicative code in slightly different order > regular store sequence >=20 > and that isn't going to be maintainable. >=20 > Look for a high-level sequence that makes sense for both cases. E.g.: >=20 > if (!zswap_enabled) > goto check_old; >=20 > get objcg >=20 > check limits >=20 > allocate memcg list lru >=20 > for each batch { > for each entry { > allocate entry > acquire objcg ref > acquire pool ref > } > compress > for each entry { > store in tree > add to lru > bump stats and counters > } > } >=20 > put objcg >=20 > return true; >=20 > check_error: > ... >=20 > and then set up the two loops such that they also makes sense when the > folio is just a single page. Thanks for this suggestion! I will explore this kind of structure. I hope I have provided some explanations as to why I pursued the existing batching structure. One other thing I wanted to add was the "future proofing" you alluded to earlier (which I will fix). Many of my design choices were motivated by minimizing latency gaps (e.g. from state unwinding in case of errors) in the batch compress pipeline when a reclaim batch of any-order folios is potentially sent to zswap. Thanks again, Kanchana