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 B02BCC3ABBE for ; Thu, 8 May 2025 21:20:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3C5C6B00A8; Thu, 8 May 2025 17:20:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEBED6B00AA; Thu, 8 May 2025 17:20:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 965DE6B00AC; Thu, 8 May 2025 17:20:17 -0400 (EDT) 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 744086B00A8 for ; Thu, 8 May 2025 17:20:17 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A135DBE691 for ; Thu, 8 May 2025 21:20:18 +0000 (UTC) X-FDA: 83421008916.09.220E703 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf07.hostedemail.com (Postfix) with ESMTP id B92DC4000C for ; Thu, 8 May 2025 21:20:16 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kR3oFqCJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746739216; a=rsa-sha256; cv=none; b=hJ0rSbSmnfkTUvtzES9Pzt5qNvWfAy9oyHwjbmQfpuzzsOqSsr93dw55XzV0vbcRscBFJQ rbsmAPCPGVjNenhORf8fvnmC2XXbN+IG2wP4Km1TweESjWrv/acf1ujDLPAwuOIr7bbJmh fjWP0LmUsF8sNQRjD/un9OvRF8tqyqw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kR3oFqCJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746739216; 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=c6ecuBg6SUtFmSzElOZogZBJCPGazdjaNlguYrKtp8U=; b=V0I4eU6hGqpy0seHynkWWgpejY1ZcEwEtjrtptEJ3V8OIQjNT6cuDF//VspZ5ybulEzbMD XbjPnX16W41mw3rpxZ5pEfk3hau/fJ5NKetcnetdpJ0NPOlc3g4ZgtBIHRYu6H1qRQ1S1e B4XNDHkWDoQUQzAPEkd5r4gkchKTwsA= Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-7cad57f88eeso97122785a.2 for ; Thu, 08 May 2025 14:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746739216; x=1747344016; 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=c6ecuBg6SUtFmSzElOZogZBJCPGazdjaNlguYrKtp8U=; b=kR3oFqCJ/Y6p98zlLTkYggibznI01QVFIXsfIWfls8ncUoCJ+OfaKIdlos4hMUB56C ukJNHr8UsgVfoZdFFzQj20mBs29BVx/AnnNH+WOY+jfhCUWDVYeYpUKvUjMXPKA4N4VM BsXSo7DS04IBxXVE3vQn0HIwhP/FzVmO/JqgnyaW21vwdiCsA3VhQWgk9TtpGc0uYm08 MBm7esWIGWY9xW6UcXLOfDxnSzqYddwOjVJRflOyAEZtrT1k1cuKupO8aE8pAvAiBicd Ne/Lw3NFsegOnYPlfaJB76VKkiYHN2JY0wf7yrDMdMR5swf7CIa+lkBKXhrFz/0ayR11 bdHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746739216; x=1747344016; 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=c6ecuBg6SUtFmSzElOZogZBJCPGazdjaNlguYrKtp8U=; b=gD3ohB+/KV9YNzy5WAQduPLxxWnQh1CTJjf1ZI9A376rLGX3DfXCOY5s2Uq6XHi943 i0UmcgcqxqzjRvsi0hMofhiBwzltyHrKM03bJj5PozohtHgfOgDHpKTy+pHjVKGJLK4m EjyftnGDTmphyMKXylRXVEOygK+KQnRVH61bn/SgI3TFuKe0lXN2wSZ124Hp8HBy4rWH Kup1mp/PuoHyEiBB6f4sRSYiZcTZ0CAZKAXq9Ul4HiVkA8jLJl7r1BqqSGAJxgs4UspW 7rgBs4KdVEtaNpP13bMlCwhh6ois5ee9PBDwMkCP9E8xgWKr/R+X4fFjfjmcyGWH9WJA S+jA== X-Forwarded-Encrypted: i=1; AJvYcCUkaeed8OJ6pgfNiji9AeSBvNNbbxfMzTy0XiyEKdmAXvzfMTi0zZZNvpx56gpswuSpx+Be/EDDOQ==@kvack.org X-Gm-Message-State: AOJu0YxI3pwH/p7NWi+AD3bSY+i7sTyQqgPBBlJ1PSlcpPSERftDEjb8 LDrzHv0f8hgSzwnu2pZxbhrhR5RwBsREMjxaOVYnGKNLHajP+bqYbAj7SbUe6du5MSZIHXj4rxY tsQEzSBf9sxoTfpdTSTS3KV9cgMw= X-Gm-Gg: ASbGncsPlPng5+Vugp0jK9ibPTbcm4Zkek0Ij91LdbDrQZSHQntpPgtvRyY0q67s1yh oOxey4LTLOyeVHH6QT3/6GH3CPepDhI/hMgi9YKFxoULr0N89HoVnU6kqv1o+brIpEH2udEtXkC 9HjkDb3V83xIEODr868gus4SFbNnwQuDKAugIpaXVICyBnHCqO X-Google-Smtp-Source: AGHT+IEUVc1Z1Ki89dIWFxYP3C8XvwQ3BlPZZbY0JKU58WTVGFqSIOXjZrvoyLsmQ4rXvkdeBmH3S5xi9ejTADbdZ3A= X-Received: by 2002:a05:6214:240d:b0:6eb:1e80:19fa with SMTP id 6a1803df08f44-6f6e47a7723mr13889426d6.1.1746739215627; Thu, 08 May 2025 14:20:15 -0700 (PDT) MIME-Version: 1.0 References: <20250508194134.28392-1-kanchana.p.sridhar@intel.com> In-Reply-To: From: Nhat Pham Date: Thu, 8 May 2025 14:20:04 -0700 X-Gm-Features: AX0GCFt5TchwkrKRR1_yOZ-6N9xtr5dZhaLGBwRa--37b4LOM6CzsjWh6Mv0h8k Message-ID: Subject: Re: [RESEND PATCH v9 00/19] zswap compression batching To: Kanchana P Sridhar Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, yosry.ahmed@linux.dev, chengming.zhou@linux.dev, usamaarif642@gmail.com, ryan.roberts@arm.com, 21cnbao@gmail.com, ying.huang@linux.alibaba.com, akpm@linux-foundation.org, senozhatsky@chromium.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, kristen.c.accardi@intel.com, vinicius.gomes@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: B92DC4000C X-Rspamd-Server: rspam04 X-Stat-Signature: 8bqyowxuyqcs1m3wu5z7wcir65em6687 X-HE-Tag: 1746739216-143841 X-HE-Meta: U2FsdGVkX194xn1zZ8LIgSu6fbxzzF2LZ5D5nTAxEffpiw+5ftKBvtcsjwT7Xt8IBdGnjY6wRblybodYBgMusALvOOovoh3/EHn41OPPY7gmz6AmM57Eaam/uKiyV70hX+vZw0vgak7p9BMLoEakTRFvr74uauSj7quaPWH+6jMXOfVcHABf23vDuG9AYYmsJRvVRKOOlR/KYlL0ZelA0QhlGhwCG4Jf3UybLfIrJShneDN4dwzkCJk8Iw8ftrldd/7mpwO87REGr2dZHYp/Lyt6zTrxijkfbMGY72PHJPfzhV8DgPe9nu6Ynm4iOpsVe6xluqzcpIO/FygHnwAQVT2G7CfphhZF4sauoXavl56ZyMZwa6FQ44KBIFXRY4M1zD0kD5s0SsdMY3F0mNVL0o7elj0HOvACDU/g2bIhZyZd9hEy3GuqXYwqDKB27JRFnd/0NQagVeR/ZWR46zqP4jzmoCMQtB/NAeOh5Y38NwoW8M/452G87O2G4bFKrBhWM4KCEpASJrmB3j6HeOmQGgUcROC/XNazX9UbNhlmSagX1r5OUPWmis9ZsWtw35SpCvFUQokBamBUUk9INFtjOtUxqcuMpGTrRY3pkAnCr/c9gnCfC41RSh1DTgtP4BENxIoPTE4uQbb+O9itGqPsCaqia+t6oFjsOPGhksFIBF14a73zp7TOBTz3qffQQz5UY0Z1Ru9BLtZMSzP3/EqQyYlPE+DRfOxOOZwd2K1mD0IEteKrFbQvloiFgszTmyOvqNha+jZk+QcoidQArcdXQ6r9qqnfPG4AlvANU/A3flTwDU+8NJGUxk4WKa4vW4RqRR2ABdTdgH0gqQK+QZ4ue6F0Gt6+pmc4qnPGDaAoia8GB6in+UvaQFjp7hgXOXkpMJYNQjcqtzF4uE4omaTDsRFlaVToCywbTCJlnhJ4mABvF5gkk9RO4CrlXHrj9fbeBG0uJ610V5HGowyfTWt oqO58IPI iHXdYHzFZJWI1B4ou8fS5M3pSVfl/Ol6Xor1uTBZEI+ay0KTWeTbw5GraYePasA5fYMp6NWrA3Nd6GZRnsKauTs5hSO4z9nbVnrkthmssPA1q+uAlJ/g3GFxsfKGooYnWgWi6zQKY0VLvQmmWbvEpBspDsta2ot1GYXTy1qjKXOuJeLJzBtxbVNat9pIn5iod27HrP0y/1/z4lqxUIvHG2e/CrUB7sGjCPPe/6702wmHThYNpWQe/feAQuXUbUWmiVSViZzyv3GK5VrNEgrM6rdJL7L2H3rVL1VNHQ8XJUE/nzusHla/MNL1wnrrmv9bZzbLLBUWCvxMIxZZtPExIdYpkt80VMQSTPz96T9nksSjPaV19XEsBU1oyANctgRmRYGH1Y9SgXs/xZGBgKjxLO9ZPPY4S5YY5KoJQ 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 Thu, May 8, 2025 at 1:55=E2=80=AFPM Nhat Pham wrote: > > On Thu, May 8, 2025 at 12:41=E2=80=AFPM Kanchana P Sridhar > wrote: > > > > > > Compression Batching: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > This patch-series introduces batch compression of pages in large folios= to > > improve zswap swapout latency. It preserves the existing zswap protocol= s > > for non-batching software compressors by calling crypto_acomp sequentia= lly > > per page in the batch. Additionally, in support of hardware accelerator= s > > that can process a batch as an integral unit, the patch-series creates > > generic batching interfaces in crypto_acomp, and calls the > > crypto_acomp_batch_compress() interface in zswap_compress() for compres= sors > > that intrinsically support batching. > > > > The patch series provides a proof point by using the Intel Analytics > > Accelerator (IAA) for implementing the compress/decompress batching API > > using hardware parallelism in the iaa_crypto driver and another proof p= oint > > with a sequential software compressor, zstd. > > Any plan on doing hardware accelerated/offloaded/parallelized zstd? :) > > > > > SUMMARY: > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > The first proof point is to test with IAA using a sequential call (fu= lly > > synchronous, compress one page at a time) vs. a batching call (fully > > asynchronous, submit a batch to IAA for parallel compression, then po= ll for > > completion statuses). > > > > The performance testing data with usemem 30 processes and kernel > > compilation test using 32 threads, show 67%-77% throughput gains an= d > > 28%-32% sys time reduction (usemem30) and 2-3% sys time reduction > > (kernel compilation) with zswap_store() large folios using IAA comp= ress > > batching as compared to IAA sequential. > > > > The second proof point is to make sure that software algorithms such = as > > zstd do not regress. The data indicates that for sequential software > > algorithms a performance gain is achieved. > > > > With the performance optimizations implemented in patches 18 and 19= of > > v9, zstd usemem30 throughput increases by 1%, along with a 6%-8% sy= s time > > reduction. With kernel compilation using zstd, we get a 0.4%-3.2% > > reduction in sys time. These optimizations pertain to common code > > paths, removing redundant branches/computes, using prefetchw() of t= he > > zswap entry before it is written, and selectively annotating branch= es > > with likely()/unlikely() compiler directives to minimize branch > > mis-prediction penalty. Additionally, using the batching code for > > non-batching compressors to sequentially compress/store batches of = up > > to ZSWAP_MAX_BATCH_SIZE (8) pages seems to help, most likely due to > > cache locality of working set structures such as the array of > > zswap_entry-s for the batch. > > Nice! > > > > > Our internal validation of zstd with the batching interface vs. IAA= with > > the batching interface on Emerald Rapids has shown that IAA > > compress/decompress batching gives 21.3% more memory savings as com= pared > > to zstd, for 5% performance loss as compared to the baseline withou= t any > > memory pressure. IAA batching demonstrates more than 2X the memory > > savings obtained by zstd at this 95% performance KPI. > > The compression ratio with IAA is 2.23, and with zstd 2.96. Even wi= th > > this compression ratio deficit for IAA, batching is extremely > > I'm confused. How does IAA give more memory savings, while having a > worse compression ratio? How do you define memory savings here? > > > beneficial. As we improve the compression ratio of the IAA accelera= tor, > > we expect to see even better memory savings with IAA as compared to > > software compressors. > > > > > > Batching Roadmap: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1) Compression batching within large folios (this series). > > > > 2) Reclaim batching of hybrid folios: > > > > We can expect to see even more significant performance and through= put > > improvements if we use the parallelism offered by IAA to do reclai= m > > batching of 4K/large folios (really any-order folios), and using t= he > > zswap_store() high throughput compression pipeline to batch-compre= ss > > pages comprising these folios, not just batching within large > > folios. This is the reclaim batching patch 13 in v1, which we expe= ct > > to submit in a separate patch-series. > > Are you aware of the current kcompressd work: > > https://lore.kernel.org/all/20250430082651.3152444-1-qun-wei.lin@mediatek= .com/ > > It basically offloads compression work into a separate kernel thread > (kcompressd), for kswapd reclaim. > > This might provide you with a more natural place to perform batch > compression - instead of compressing one page at a time from the > worker thread's queue, you can grab a batch worth of pages and feed it > to IAA. > > Downside is it only applies to indirect reclaim. Proactive and direct > reclaimers are not covered, unfortunately. > > > > > 3) Decompression batching: > > > > We have developed a zswap load batching interface for IAA to be us= ed > > for parallel decompression batching, using swapin_readahead(). > > > > These capabilities are architected so as to be useful to zswap and > > zram. We are actively working on integrating these components with zr= am. > > Yeah problem with readahead is you can potentially get different > backends in the batch, and modifying readahead code is pretty ugly :) > But we'll see... > Another place where you can do decompression batching is for zswap writeback :) Right now, we are decompressing the pages and writing them back one page at a time. You can, however, grab a batch worth of them, feed to IAA for processing, before submitting them all for IO :) I have a prototype that perform batch writeback (mostly for IO efficiency purpose) - lmk if you want to play with it. Problem, as usual, is benchmarking :)