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 18C3CD64099 for ; Fri, 8 Nov 2024 22:54:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F1988D0002; Fri, 8 Nov 2024 17:54:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 979FA6B009B; Fri, 8 Nov 2024 17:54:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81CA88D0002; Fri, 8 Nov 2024 17:54: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 602916B009A for ; Fri, 8 Nov 2024 17:54:51 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5E86D80FC2 for ; Fri, 8 Nov 2024 22:54:50 +0000 (UTC) X-FDA: 82764433206.26.EE02737 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf10.hostedemail.com (Postfix) with ESMTP id 0C18DC001B for ; Fri, 8 Nov 2024 22:54:31 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GePR8vfg; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731106437; 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=XTgfqzvVEJgSL3F6tF2AjJ65IStRvvSqyUo9L5oq5Xo=; b=np1p54/puJ0taYzy8IMGC8NyZPlhbNSm1qfX6OWAzcl4eMN7JCvWpQAz7a3TJG3YsE+m1J KPiuI4ypyfDfmR5fGDyoqFMw/TmRHZUBB/th2iZjahm/jhXxFoDJ70+QOtcoGHrRNtQ2CF BAL/8Kv9PjUkasHVUBD0rfV1lni895s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731106437; a=rsa-sha256; cv=none; b=hlKro14dIWJM6PC6CdvDlQLAY3Xj+lY+4xC3JkhoMIBSSrEOJvTOxigTB9AryR+r26L18t WvDIdFu/w4aSka/SYnKj8yEpWr8Q9Q+NP+BCGcFMmJJwFoC5WwX5n3kdECM5wHS0VCFztj 8U8kxDX2/LCWF/Xbq6HCphY7H3CiCS8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GePR8vfg; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-50d399891d6so756756e0c.1 for ; Fri, 08 Nov 2024 14:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731106488; x=1731711288; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XTgfqzvVEJgSL3F6tF2AjJ65IStRvvSqyUo9L5oq5Xo=; b=GePR8vfg5BMUtzELNno/qzyoBX7ITKMcZ557X0QlKA55dzHFAQhiS7rrRyTu5ktu3r zJpAGTaKhzc+CapgHNehyr107F1X//jMuJxtSyMNVgnRONcO8Iy2vDC06Yg4+H27EghH V3pmNmC6lOkvWNbibhcT6Leb0myb/0Nq87gaQXxKbwxhefnM88daYdQ939SzItuMgfgZ PQSwm/pSxe2T1FYiEXa9fFJvs4Ti2vtT0N4lsnf5reQ8noICtZYlxYnKQTqI44o/fgcl efoZjv0b92JAkFBosv9PC0KQpu1iPCTkDMzT8DvgEpYPytsoO/t3pFVlu7SwTZZoxz01 ELpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731106488; x=1731711288; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XTgfqzvVEJgSL3F6tF2AjJ65IStRvvSqyUo9L5oq5Xo=; b=rio5sX+aLD+n+sC/Xf8wb5+DEKhcPI2zbZBChU0in+Sm5jPTKtXySBqwymP93bFrLK mtTdKdKIxpe0S+8idjXKAO4fX4YUb5KFQ3rIJhfbXhmffIFoihz/5iHDry0LsxEsSB/K qT8HOOLXUJiPhZR/0M6eW19Y2BP2WqJCbzKeewDaKoLa/yr/YhWR/qyPMVQyruITPU9t ocjHwSfbn1I+pEz77vXSmVp3RA1cc0HT3hGCKKK8L0W3OSti5m6KFg4Z6bE7vfdKk/vl ET2gjVZYbXVnHGiMEa0oR3mhyt3rlMkJTcqDHbhxkojc2dXFSE9cQjdY95fWj0EurfBc VTEw== X-Forwarded-Encrypted: i=1; AJvYcCWpjjG4iQBwoGbz0shDUeAJ3wNjU7ZBeZdA6GHhUuBqAZSuKyakqkfgLEqYjBQcih13HbKBtnoxew==@kvack.org X-Gm-Message-State: AOJu0Yy9D7gAAq7shfEk2DMFZMq5W1y1X+8YD2chyK9hrors3kkr27GQ sBARWxGDwxDKrnt6vUnEd9YK46GrDN7HHRXpnqBT/Fcw2tkCt0/8MjihxqY2va2L5K5C5ORiU5a 5PwNBXwrIFnbxewoF8oXQZQ8CR4I6DqHTfbgd X-Google-Smtp-Source: AGHT+IEtiRf/T78bxWlsBc3bfUJoidKtGZy3ydKaQ6zD7zxf8cet8W15HcX4ar86tVuT+7NOnyb//BJIhfJ1TKwDVAQ= X-Received: by 2002:a05:6122:1e12:b0:50d:918d:4da1 with SMTP id 71dfb90a1353d-51401ba59e4mr5503150e0c.3.1731106487467; Fri, 08 Nov 2024 14:54:47 -0800 (PST) MIME-Version: 1.0 References: <20241106192105.6731-1-kanchana.p.sridhar@intel.com> <20241106192105.6731-10-kanchana.p.sridhar@intel.com> <20241107172056.GC1172372@cmpxchg.org> In-Reply-To: From: Yosry Ahmed Date: Fri, 8 Nov 2024 14:54:11 -0800 Message-ID: Subject: Re: [PATCH v3 09/13] mm: zswap: Modify struct crypto_acomp_ctx to be configurable in nr of acomp_reqs. To: "Sridhar, Kanchana P" Cc: Johannes Weiner , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "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" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: fuox8c1ye3tyk418bkdrnkxhhghibucm X-Rspam-User: X-Rspamd-Queue-Id: 0C18DC001B X-Rspamd-Server: rspam02 X-HE-Tag: 1731106471-484034 X-HE-Meta: U2FsdGVkX1+eLMKqh9Cw58e3qDq7jmzPlJqPnyaEheXSJ4H3yRYmeZ3IihagKZj0wrBjMds2nW6EVwV+SvmVPZNKEm9UV8kZydXFQjfLPEp0aagjUKeQQczbW55ZuTDrabJewyYqCsfZGjbPE3ZFQ32tIjoWfOFD+ZZ+UzDivduteogH6+UJU7syHWPVi/hAInU8AOQUYabRZO8PyRwVaf15SowMsJKM3vglchGHghzD/xqnj03a48Q8QUkfdndSBm2e/2QKpY3abShZf/aVmcXqf+H5uncnL/+H1QVkuvVjDCI9WRukQ02OTFmxihWYOj2rP4Z3mlu+rWDAVfLQQivYxnynI6u3bT+3Dd8QK8cBnuMJySHIvN8jw4Jw6DNzig2AhfDELlrHUwetqbHzE8Y5gG1ZXt7Vdp0XwD8ZKpQWyWkrC8X1MvIBhofPC9tzappGPWn35DEtzsHLd04Daa4hNmjytHI5iwpReQyrVV+agMcqYVsHih0bVwBa5lXuE08Sdeq2boGGXWsdxJukHBJdMhmvPWEpRq41EzJudbkAd1lTN55ZT8U2AGPoSFbnXNq+ovnQfPBygza6hfEB9CI0fw8W8m5l8zDVoRU7DcYCESde5ldUicuaepelHPRlOdDV2qrsD6I/9Hwv5Vr/lKYpBxKYWSqfkKY3wLalyqg+0ijIWGzEaguqg7v4cj34LIvApOzFiQWsMymnJiTdcR6TkeT1QLs1rPVukNo6app7JUHJhr0tkh9oxJAuaBQPtsU7lXobsDV4W54iAOUKLyIjbS/3vCcwy5OPeZC6c0O0xVr1+jb28Nsc8JlmpEE450F8Nx7BaVxznJypA4DQFiake59NsYwVu+g5BB+sVLHLWF9FB2G5nw5Zt4mW+U9DN1hBN+Kic9tZp8l5eM0sc5aqN5bRHIbAGrPMTBSoQAc5pvOkrAEGMhRL70beBqhC5pgdTSenF57OlLLnJG9 IsNMDvEC 1Jx9PyxIulUQApXN4rMRBsNzCbvtk76YWtD8MAwDm+YC7WTK/ge8ink3wiTJzyriBruSYWEh8bNJXPGR8+/DnwGmGGgGAvg5IK7WdGFq1cu/fsMbyjcxe6MvI7ZBQoyWbC38OvLIchr7oAmqlD+sgG4UjI0H31QHGisch9DDekLRPVZErRsLnnQ5FfOls7cKmvhB4GwFFczgMGbGqXJXsDlAomOCFEJEVZsQCPwZF6Yd8V7DLGIDW1mXIT1CMkx2JWGwiZwVUQM+/s6ukAb+KaKkGu5IQP2BZz3AO 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: [..] > > > > > > > > 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 commits. > > > > > > 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- > > facto > > > pool->acomp_ctx for the selected compressor for all cpu's in > > zswap_pool_create(). > > > 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 > > the > > > memory cost on all cpu's. > > > > > > Instead, the approach I chose to follow is to allocate the batching resources > > > in patch 11 only as needed, on "a given cpu" that has to store a large folio. > > Hope > > > this explains the purpose of the modularization better. > > > > > > Other ideas towards accomplishing this are very welcome. > > > > If we remove the sysctl as suggested by Johannes, then we can just > > allocate the number of buffers based on the compressor and whether it > > supports batching during the pool initialization in the cpu callbacks > > only. > > > > Right? > > Yes, we could do that if the sysctl is removed, as suggested by Johannes. > The only "drawback" of allocating the batching resources (assuming the > compressor allows batching) would be that the memory footprint penalty > would be incurred on every cpu. I was trying to further economize this > cost based on whether a given cpu actually needs to zswap_store() a > large folio, and only then allocate the batching resources. Although, I am > not sure if this would benefit any usage model. > > If we agree the pool initialization is the best place to allocate the batching > resources, then I will make this change in v4. IIUC the additional cost would apply if someone wants to use deflate-iaa on hardware that supports batching but does not want to use batching. I don't think catering to such a use case warrants the complexity in advance, not until we have a user that genuinely cares.