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 68733E74ADB for ; Tue, 3 Dec 2024 21:44:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF7EB6B0083; Tue, 3 Dec 2024 16:44:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E80B76B0085; Tue, 3 Dec 2024 16:44:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D21B46B0088; Tue, 3 Dec 2024 16:44:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AD2696B0083 for ; Tue, 3 Dec 2024 16:44:39 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 57B4FC0C53 for ; Tue, 3 Dec 2024 21:44:39 +0000 (UTC) X-FDA: 82854976932.13.A7DEBA3 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf14.hostedemail.com (Postfix) with ESMTP id 6E657100004 for ; Tue, 3 Dec 2024 21:44:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IvEll7hu; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733262271; 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=vm0D9iLih6NVgJOSSK56eoyE8s/0Ie0xteOxyeVsYIs=; b=i9/XL68UCBvAD+KFG2B/2krzlf1AYsS/Lx28DgYLiOhSj0dmhoYFbr6P7qi64tnxch0RQK NWAECYhRLlS1a2+Q/fRgGQEz2XF1WvY1/mTvfnL1VjxeTqbwTeg28nvih6fUy1HN5GqWtw okebD+wIwiEIEMjjjcJ6HoOSAvC1R4s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733262271; a=rsa-sha256; cv=none; b=wYoJ+R2ey/vKRS9do1BSOhzp96wRS465is5ISHRzQyp5J9F65by+wr1e+bbe/B7+43m0GW 4by6Z1b0SokSYnRgKBLSp5MqrOASgE8Q/+hav02dRbIyzHhoQREclYv8tTWOs3fu5uZZCH nulQt4zs5yymqQ9xVNXDSQzFpjc2kUs= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IvEll7hu; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-6d89811946eso26107746d6.2 for ; Tue, 03 Dec 2024 13:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733262276; x=1733867076; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vm0D9iLih6NVgJOSSK56eoyE8s/0Ie0xteOxyeVsYIs=; b=IvEll7hu7M+Ub+OQRDVgSGvlaGl4gqMH9Ubd1elHvRn8tv8sKEue4sT6hwUu4cVGCO zHn3FKT6HFrasia3JHIT3tTuL+gS/B6q/aedYaL1mJTwJz580/0NNhRX5dVsLoT+5qak BaWjx5+Va2F4mQGahy8R4Zn4IWYEwq73z5onJFowhEfwrafQfdaoChKkdhpaiA26IpV7 LIx7srrZG0kKe7EecIkbQR/0r352U0G4g54XfegUmnXlIwSTW+NQhPf3SPKFMe1eVKB+ TOHP2Du/MVs8WmvD1Tlk16f5HOpLHbTK2lUZYI4nW99vCImZ8r1YXwohD5+xotdLtpVL q0DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733262276; x=1733867076; h=content-transfer-encoding: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=vm0D9iLih6NVgJOSSK56eoyE8s/0Ie0xteOxyeVsYIs=; b=aaZv4iWP7MvbU65kOOXiS7mG8WFqGiqPCTKDHbBfL1J/FNR4PP0UwkL1iSmZcVgQLU m1otY6lX0JtkKwZCBdz80Ff3gCph3JPPnQA1wtz1TjYIoirhrz/kdiQfE4iNVolffCh7 ov8HrEC2RhXUboBxrtonC0SZGGT1kEviD2M42Ej62IIwCzBHwx2d3Tr662QPSnecxd1f k4V9KKa08vxT7kxpX0PGEKZusUy61flP599So9UBbubzJNsQSAbWPHBVgJ2D6uJ/dJsp NaJRQOkchbci2/B2SYaubjxAiyi4QXHPBiegdY1btccdgqGO/ycKHZGvvbNWmLB6KIX5 2SUQ== X-Forwarded-Encrypted: i=1; AJvYcCWREkUAOnwQTxa9DZ+5pipooSqW24/eVE0jEgkc+PJzWTwR31KIEZepxkTPStudm+amM48+M/v3iw==@kvack.org X-Gm-Message-State: AOJu0YxNu4v74WZZOah3u9TqrHncaYUWfDARANbyuvKzgxLvRxg5stAb MPa/rzTa5Ly4KrUg6ht1n9GJRyClBxIzJlCejwG7H7ftezsZ4BT+IC0ksO4bgVnoPAp55nMqiLl pwa/qd+5FXMoCDHncIM3XXn68/XXLekCmG8td X-Gm-Gg: ASbGncvc7oggqwKWF1kJDKGpIakob8+EplruQw/amKDa2F92+O7161imMMa3CQfuPNW RMcrU7PcETQtvAZZzBf+EonTwWlXY X-Google-Smtp-Source: AGHT+IElgjsMKzyb8pB6S2q5z1oqGiduDeQK5SqLnhC4d+BQTcWkNixPgmGxlQy2kLoTb/AFWhq1uk9LZWaoSMS148s= X-Received: by 2002:a05:6214:5183:b0:6d8:a84b:b50d with SMTP id 6a1803df08f44-6d8c46bd285mr28938446d6.33.1733262276441; Tue, 03 Dec 2024 13:44:36 -0800 (PST) MIME-Version: 1.0 References: <20241123070127.332773-1-kanchana.p.sridhar@intel.com> <20241123070127.332773-10-kanchana.p.sridhar@intel.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 3 Dec 2024 13:44:00 -0800 Message-ID: Subject: Re: [PATCH v4 09/10] mm: zswap: Allocate pool batching resources if the crypto_alg supports batching. To: "Sridhar, Kanchana P" Cc: Herbert Xu , Nhat Pham , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "ying.huang@intel.com" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: r74ik8zo37sgyq5qfmutz3ajndeku3mh X-Rspamd-Queue-Id: 6E657100004 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733262262-675026 X-HE-Meta: U2FsdGVkX1+ybCzVTtA7phpsoOVBU9svyWzZMz3Gy4dniZA6XqIkm0UFUh2UnIr7mQGg1EEEA6k2GiR+X78AbKXDz2KhNQUawarAxRsC0HOeRQeWw0omMcTdShrJZvBUMRZTy2VSYSqXjS4GVh3Zj3jCtivSHi7lBHDzeohMq+2y0e/TS9okUc3GLK+Lhmyx16JYysJ3uGHLmEmDB3oqdJx/inaSzCGmeuNGbN5EDy3Nnwpg/LpP0RYYTffgb5dy/EZE3lnkvwJqZnH0Cn6tprdxku0SwaErHr/xOqMC42wIxtkmsUCkkuyPjiF1p8GvxaZk1eWX48RkY32NJn3f5lthHUWLgvQ1AkUVtYLJMXYM3HpIC7QxksQ7xK1exZnopaJzxdk7+gLFzBLfhdV7flZ8As6L+OZLVXe99MEY6oKf8IL9eXuOo1aDiYYl/Bku7FkKnKD9tXmuySBk7zyzFCo5mpSABKupdCRRNIDtUZ+rsZuQwXLllhUQQNSYeZSzT33iXW+l2I5OzHTW8J2CZ4NIbv/6doLZG7IaslRTeOvgASfXLT6KM+FN5kYpBKlBf0adT5yLUGlzm5Udj26gQFBxpF0T+X23us3SPmR3s4PCycz37cld+DEcvZNi/TEw59ZkQuo1q6mwrX11i/CgOO7mCaZEB5Kqhxs94khmTa+4j3Ii7abslJfeF22/Ed/JnTTc8Dsr03JgnZQqF/dSjeQE1i812B0C0MF6T40Ga2Fii2FRM2SaEWSrDBBj/1pV3wqXH5oBGA/2P8PUfa+FhohCgS8tJZGZ4//me5a3CKiNLc4p8HRnkboq8dqCOkO8NtHu9rfebwS/Pn/MAB7TAFqaujHAimd5Mryhdj1O/For8LZXIQjc1D2pC6O/UHANewuzViL537doYu+LJWWIqE8Gk+qFN8YLPt9ZvMwyxTHPeylKEgg9BoVb10iHnp3j2i/BG3LZjI1jhmy6Cjh WL6f5S8/ Z4+CWO7jD7oCU2V6rhmNePRmKCcEACLZhPL4imY6oc1ThVvyDwVHdD25pyXPE+ATW90o1cUxOTKt6QsqG7fcQMEvcvvVukjY8bYPFPtXMePzVzCiTzYn1kSN9FdWyKeE3kmOjC2dJUk/hhkKW8OnT0NQuU/c0AoWfa0FmGLRD4rzRwCGbsznMWjDhD5oYhVm021OqYrKN7/e+QUQRP0soFDBaPevdjEHUj4AuK4BC6Fi5DeXVdsZ1Cojpk6slwY1iPbemFmdgmgv9dDo8TK8YiPsXzT7gNXJv88k0cuRhFrINlG92G/imodycl603BEOPzhnmxVvrc13J/p50ZEG6O4gD63JIEZTV7cLKVHSkiFszMUpSBGQWOI5CSaXkgOTmkXD9nRjtQsSJ2CWrCEKqsTMBuHBMSVWVdH/UwF5M3ljisiaGSXUJhWpnMrJNbZLu7oLVrUpvIiNQ4+LjIILEDYPQ4suCqYWDNtMnwU5Ol0Uahjyz1YN4l6kxFQAC7nKEzjVHSNV09N/mEVdsqmVIY8m3OJU1/gJunuY0FMv4WndAxH+4Na0Zxdpk5Mm5MinrW6r+HCCy/h+FFeSltOaT3bVKh23L+l2asN320DhlyxiXrsl5H3L19r+9AG6wUrCRw8BVmFOX+uLuZKGWRaTgUr5Wp++J+6CEzpHqIdTL6kFRA2zQYPa+dPvkDsyHgWUz/jqIb0orrMy28BTsGjHqQHs99vtEIcD2a44pNemrji28KBY1yV4G5fxqYQ/mQMgtCdYP9iysVRNP1txqjZ0bAheF95O6lhw85Ze+ 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, Dec 3, 2024 at 1:37=E2=80=AFPM Sridhar, Kanchana P wrote: > > > > -----Original Message----- > > From: Herbert Xu > > Sent: Tuesday, December 3, 2024 12:01 AM > > To: Sridhar, Kanchana P > > Cc: Nhat Pham ; linux-kernel@vger.kernel.org; linux- > > mm@kvack.org; hannes@cmpxchg.org; yosryahmed@google.com; > > chengming.zhou@linux.dev; usamaarif642@gmail.com; > > ryan.roberts@arm.com; ying.huang@intel.com; 21cnbao@gmail.com; > > akpm@linux-foundation.org; linux-crypto@vger.kernel.org; > > 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 v4 09/10] mm: zswap: Allocate pool batching resourc= es if > > the crypto_alg supports batching. > > > > On Tue, Dec 03, 2024 at 12:30:30AM +0000, Sridhar, Kanchana P wrote: > > > > > > > Why do we need this "can_batch" field? IIUC, this can be determined > > > > from the compressor internal fields itself, no? > > > > > > > > acomp_has_async_batching(acomp); > > > > > > > > Is this just for convenience, or is this actually an expensive thin= g to > > compute? > > > > > > Thanks for your comments. This is a good question. I tried not to imp= ly that > > > batching resources have been allocated for the cpu based only on what > > > acomp_has_async_batching() returns. It is possible that the cpu onlin= ing > > > code ran into an -ENOMEM error on any particular cpu. In this case, I= set > > > the pool->can_batch to "false", mainly for convenience, so that zswap > > > can be somewhat insulated from migration. I agree that this may not b= e > > > the best solution; and whether or not batching is enabled can be dire= ctly > > > determined just before the call to crypto_acomp_batch_compress() > > > based on: > > > > > > acomp_ctx->nr_reqs =3D=3D SWAP_CRYPTO_BATCH_SIZE; > > > > With ahash request chaining, the idea is to accumulate as much > > data as you can before you provide it to the Crypto API. The > > API is responsible for dividing it up if the underlying driver > > is only able to handle one request at a time. > > > > So that would be the ideal model to use for compression as well. > > Provide as much data as you can and let the API handle the case > > where the data needs to be divided up. > > Thanks for this suggestion! This sounds like a clean way to handle the > batching/sequential compress/decompress within the crypto API as long > as it can be contained in the crypto acompress layer. > If the zswap maintainers don't have any objections, I can look into the > feasibility of doing this. Does this mean that instead of zswap breaking down the folio into SWAP_CRYPTO_BATCH_SIZE -sized batches, we pass all the pages to the crypto layer and let it do the batching as it pleases? It sounds nice on the surface, but this implies that we have to allocate folio_nr_pages() buffers in zswap, essentially as the allocation is the same size as the folio itself. While the allocation does not need to be contiguous, making a large number of allocations in the reclaim path is definitely not something we want. For a 2M THP, we'd need to allocate 2M in zswap_store(). If we choose to keep preallocating, assuming the maximum THP size is 2M, we need to allocate 2M * nr_cpus worth of buffers. That's a lot of memory. I feel like I am missing something. > > Thanks, > Kanchana > > > > > Cheers, > > -- > > Email: Herbert Xu > > Home Page: http://gondor.apana.org.au/~herbert/ > > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt