* Re: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios.
[not found] <20250303084724.6490-15-kanchana.p.sridhar@intel.com>
@ 2025-03-03 11:07 ` kernel test robot
2025-03-03 18:21 ` Nhat Pham
0 siblings, 1 reply; 5+ messages in thread
From: kernel test robot @ 2025-03-03 11:07 UTC (permalink / raw)
To: Kanchana P Sridhar, linux-kernel, linux-mm, hannes, yosry.ahmed,
nphamcs, chengming.zhou, usamaarif642, ryan.roberts, 21cnbao,
ying.huang, akpm, linux-crypto, herbert, davem, clabbe, ardb,
ebiggers, surenb, kristen.c.accardi
Cc: llvm, oe-kbuild-all, wajdi.k.feghali, vinodh.gopal,
kanchana.p.sridhar
Hi Kanchana,
kernel test robot noticed the following build errors:
[auto build test ERROR on 5f089a9aa987ccf72df0c6955e168e865f280603]
url: https://github.com/intel-lab-lkp/linux/commits/Kanchana-P-Sridhar/crypto-acomp-Add-synchronous-asynchronous-acomp-request-chaining/20250303-164927
base: 5f089a9aa987ccf72df0c6955e168e865f280603
patch link: https://lore.kernel.org/r/20250303084724.6490-15-kanchana.p.sridhar%40intel.com
patch subject: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios.
config: s390-randconfig-001-20250303 (https://download.01.org/0day-ci/archive/20250303/202503031847.j1iReOtf-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250303/202503031847.j1iReOtf-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202503031847.j1iReOtf-lkp@intel.com/
All errors (new ones prefixed by >>):
>> mm/zswap.c:1166:4: error: call to undeclared function 'prefetchw'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1166 | prefetchw(entries[j]);
| ^
1 error generated.
vim +/prefetchw +1166 mm/zswap.c
1053
1054 /*
1055 * Unified code paths for compressors that do and do not support
1056 * batching. This procedure will compress multiple @nr_pages in @folio,
1057 * starting from @index.
1058 * If @batching is set to true, it will create a request chain for
1059 * compression batching. It is assumed that the caller has verified
1060 * that the acomp_ctx->nr_reqs is at least @nr_pages.
1061 * If @batching is set to false, it will process each page sequentially.
1062 * In both cases, if all compressions were successful, it will proceed
1063 * to store the compressed buffers in zpool.
1064 */
1065 static bool zswap_batch_compress(struct folio *folio,
1066 long index,
1067 unsigned int nr_pages,
1068 struct zswap_entry *entries[],
1069 struct zswap_pool *pool,
1070 struct crypto_acomp_ctx *acomp_ctx,
1071 bool batching)
1072 {
1073 struct scatterlist inputs[ZSWAP_MAX_BATCH_SIZE];
1074 struct scatterlist outputs[ZSWAP_MAX_BATCH_SIZE];
1075 struct zpool *zpool = pool->zpool;
1076 int acomp_idx = 0, nr_to_store = 1;
1077 unsigned int i, j;
1078 int err = 0;
1079 gfp_t gfp;
1080
1081 lockdep_assert_held(&acomp_ctx->mutex);
1082
1083 gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM;
1084 if (zpool_malloc_support_movable(zpool))
1085 gfp |= __GFP_HIGHMEM | __GFP_MOVABLE;
1086
1087 for (i = 0; i < nr_pages; ++i) {
1088 struct page *page = folio_page(folio, index + i);
1089
1090 sg_init_table(&inputs[acomp_idx], 1);
1091 sg_set_page(&inputs[acomp_idx], page, PAGE_SIZE, 0);
1092
1093 /*
1094 * Each dst buffer should be of size (PAGE_SIZE * 2).
1095 * Reflect same in sg_list.
1096 */
1097 sg_init_one(&outputs[acomp_idx], acomp_ctx->buffers[acomp_idx], PAGE_SIZE * 2);
1098 acomp_request_set_params(acomp_ctx->reqs[acomp_idx], &inputs[acomp_idx],
1099 &outputs[acomp_idx], PAGE_SIZE, PAGE_SIZE);
1100
1101 if (batching) {
1102 /* Add the acomp request to the chain. */
1103 if (likely(i))
1104 acomp_request_chain(acomp_ctx->reqs[acomp_idx], acomp_ctx->reqs[0]);
1105 else
1106 acomp_reqchain_init(acomp_ctx->reqs[0], 0, crypto_req_done,
1107 &acomp_ctx->wait);
1108
1109 if (i == (nr_pages - 1)) {
1110 /* Process the request chain. */
1111 err = crypto_wait_req(crypto_acomp_compress(acomp_ctx->reqs[0]), &acomp_ctx->wait);
1112
1113 /*
1114 * Get the individual compress errors from request chaining.
1115 */
1116 for (j = 0; j < nr_pages; ++j) {
1117 if (unlikely(acomp_request_err(acomp_ctx->reqs[j]))) {
1118 err = -EINVAL;
1119 if (acomp_request_err(acomp_ctx->reqs[j]) == -ENOSPC)
1120 zswap_reject_compress_poor++;
1121 else
1122 zswap_reject_compress_fail++;
1123 }
1124 }
1125 /*
1126 * Request chaining cleanup:
1127 *
1128 * - Clear the CRYPTO_TFM_REQ_CHAIN bit on acomp_ctx->reqs[0].
1129 * - Reset the acomp_ctx->wait to notify acomp_ctx->reqs[0].
1130 */
1131 acomp_reqchain_clear(acomp_ctx->reqs[0], &acomp_ctx->wait);
1132 if (unlikely(err))
1133 return false;
1134 j = 0;
1135 nr_to_store = nr_pages;
1136 goto store_zpool;
1137 }
1138
1139 ++acomp_idx;
1140 continue;
1141 } else {
1142 err = crypto_wait_req(crypto_acomp_compress(acomp_ctx->reqs[0]), &acomp_ctx->wait);
1143
1144 if (unlikely(err)) {
1145 if (err == -ENOSPC)
1146 zswap_reject_compress_poor++;
1147 else
1148 zswap_reject_compress_fail++;
1149 return false;
1150 }
1151 j = i;
1152 nr_to_store = 1;
1153 }
1154
1155 store_zpool:
1156 /*
1157 * All batch pages were successfully compressed.
1158 * Store the pages in zpool.
1159 */
1160 acomp_idx = -1;
1161 while (nr_to_store--) {
1162 unsigned long handle;
1163 char *buf;
1164
1165 ++acomp_idx;
> 1166 prefetchw(entries[j]);
1167 err = zpool_malloc(zpool, acomp_ctx->reqs[acomp_idx]->dlen, gfp, &handle);
1168
1169 if (unlikely(err)) {
1170 if (err == -ENOSPC)
1171 zswap_reject_compress_poor++;
1172 else
1173 zswap_reject_alloc_fail++;
1174
1175 return false;
1176 }
1177
1178 buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO);
1179 memcpy(buf, acomp_ctx->buffers[acomp_idx], acomp_ctx->reqs[acomp_idx]->dlen);
1180 zpool_unmap_handle(zpool, handle);
1181
1182 entries[j]->handle = handle;
1183 entries[j]->length = acomp_ctx->reqs[acomp_idx]->dlen;
1184 ++j;
1185 }
1186 }
1187
1188 return true;
1189 }
1190
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios.
2025-03-03 11:07 ` [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios kernel test robot
@ 2025-03-03 18:21 ` Nhat Pham
2025-03-03 21:34 ` Sridhar, Kanchana P
0 siblings, 1 reply; 5+ messages in thread
From: Nhat Pham @ 2025-03-03 18:21 UTC (permalink / raw)
To: kernel test robot
Cc: Kanchana P Sridhar, linux-kernel, linux-mm, hannes, yosry.ahmed,
chengming.zhou, usamaarif642, ryan.roberts, 21cnbao, ying.huang,
akpm, linux-crypto, herbert, davem, clabbe, ardb, ebiggers,
surenb, kristen.c.accardi, llvm, oe-kbuild-all, wajdi.k.feghali,
vinodh.gopal
On Mon, Mar 3, 2025 at 3:07 AM kernel test robot <lkp@intel.com> wrote:
>
> Hi Kanchana,
>
> kernel test robot noticed the following build errors:
>
> > 1166 prefetchw(entries[j]);
> --
Why are we doing this anyway? Does it have a notable performance
difference? At the very least, leave a comment explaining why we're
prefetching this (although the build error suggests that we have to
remove it anyway).
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios.
2025-03-03 18:21 ` Nhat Pham
@ 2025-03-03 21:34 ` Sridhar, Kanchana P
2025-03-06 21:20 ` Yosry Ahmed
0 siblings, 1 reply; 5+ messages in thread
From: Sridhar, Kanchana P @ 2025-03-03 21:34 UTC (permalink / raw)
To: Nhat Pham, lkp
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,
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,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
Feghali, Wajdi K, Gopal, Vinodh, Sridhar, Kanchana P
> -----Original Message-----
> From: Nhat Pham <nphamcs@gmail.com>
> Sent: Monday, March 3, 2025 10:22 AM
> To: lkp <lkp@intel.com>
> Cc: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>; 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; 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
> <kristen.c.accardi@intel.com>; llvm@lists.linux.dev; oe-kbuild-
> all@lists.linux.dev; Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal,
> Vinodh <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v8 14/14] mm: zswap: Compress batching with request
> chaining in zswap_store() of large folios.
>
> On Mon, Mar 3, 2025 at 3:07 AM kernel test robot <lkp@intel.com> wrote:
> >
> > Hi Kanchana,
> >
> > kernel test robot noticed the following build errors:
> >
> > > 1166 prefetchw(entries[j]);
> > --
>
> Why are we doing this anyway? Does it have a notable performance
> difference? At the very least, leave a comment explaining why we're
> prefetching this (although the build error suggests that we have to
> remove it anyway).
Hi Nhat,
Yes, it does. The use of prefetchw reduces sys time by ~1.5% because
it minimizes cache-miss latency by moving the zswap entry to the cache
before it is written to.
This is data with kernel compilation test, v8 without prefetchw and v8 as-is:
--------------------------------------------------------------------------------
Kernel compile v8 without v8 v8 without v8
allmodconfig prefetchw prefetchw
2M folios
--------------------------------------------------------------------------------
zswap compressor deflate-iaa deflate-iaa zstd zstd
--------------------------------------------------------------------------------
real_sec 732.89 735.63 768.53 758.21
user_sec 15,708.37 15,699.84 15,702.64 15,678.73
sys_sec 4,632.58 4,563.70 5,735.06 5,635.69
--------------------------------------------------------------------------------
Max_Res_Set_Size_KB 1,874,672 1,867,516 1,874,684 1,872,888
--------------------------------------------------------------------------------
memcg_high 0 0 0 0
memcg_swap_fail 0 0 0 0
zswpout 114,742,930 112,836,725 92,904,961 89,596,085
zswpin 41,184,897 39,983,793 31,018,149 29,163,932
pswpout 625 1,069 558 1,059
pswpin 599 1,056 540 1,051
thp_swpout 1 2 1 2
thp_swpout_fallback 10,967 10,195 6,918 6,141
pgmajfault 42,588,331 41,349,069 31,931,882 30,006,422
ZSWPOUT-2048kB 7,661 8,710 6,799 7,480
SWPOUT-2048kB 1 2 1 2
--------------------------------------------------------------------------------
Sure, I will add a comment, and also "#include <linux/prefetch.h>" in zswap.c
that will resolve the build error. This is similar to how these files handle prefetchw:
mm/vmscan.c, kernel/locking/qspinlock.c, include/asm-generic/xor.h, etc.
Thanks,
Kanchana
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios.
2025-03-03 21:34 ` Sridhar, Kanchana P
@ 2025-03-06 21:20 ` Yosry Ahmed
2025-04-30 21:07 ` Sridhar, Kanchana P
0 siblings, 1 reply; 5+ messages in thread
From: Yosry Ahmed @ 2025-03-06 21:20 UTC (permalink / raw)
To: Sridhar, Kanchana P
Cc: Nhat Pham, lkp, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
hannes@cmpxchg.org, chengming.zhou@linux.dev,
usamaarif642@gmail.com, ryan.roberts@arm.com, 21cnbao@gmail.com,
ying.huang@linux.alibaba.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,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
Feghali, Wajdi K, Gopal, Vinodh
On Mon, Mar 03, 2025 at 09:34:04PM +0000, Sridhar, Kanchana P wrote:
>
> > -----Original Message-----
> > From: Nhat Pham <nphamcs@gmail.com>
> > Sent: Monday, March 3, 2025 10:22 AM
> > To: lkp <lkp@intel.com>
> > Cc: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>; 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; 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
> > <kristen.c.accardi@intel.com>; llvm@lists.linux.dev; oe-kbuild-
> > all@lists.linux.dev; Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal,
> > Vinodh <vinodh.gopal@intel.com>
> > Subject: Re: [PATCH v8 14/14] mm: zswap: Compress batching with request
> > chaining in zswap_store() of large folios.
> >
> > On Mon, Mar 3, 2025 at 3:07 AM kernel test robot <lkp@intel.com> wrote:
> > >
> > > Hi Kanchana,
> > >
> > > kernel test robot noticed the following build errors:
> > >
> > > > 1166 prefetchw(entries[j]);
> > > --
> >
> > Why are we doing this anyway? Does it have a notable performance
> > difference? At the very least, leave a comment explaining why we're
> > prefetching this (although the build error suggests that we have to
> > remove it anyway).
>
> Hi Nhat,
>
> Yes, it does. The use of prefetchw reduces sys time by ~1.5% because
> it minimizes cache-miss latency by moving the zswap entry to the cache
> before it is written to.
>
> This is data with kernel compilation test, v8 without prefetchw and v8 as-is:
>
> --------------------------------------------------------------------------------
> Kernel compile v8 without v8 v8 without v8
> allmodconfig prefetchw prefetchw
> 2M folios
> --------------------------------------------------------------------------------
> zswap compressor deflate-iaa deflate-iaa zstd zstd
> --------------------------------------------------------------------------------
> real_sec 732.89 735.63 768.53 758.21
> user_sec 15,708.37 15,699.84 15,702.64 15,678.73
> sys_sec 4,632.58 4,563.70 5,735.06 5,635.69
> --------------------------------------------------------------------------------
> Max_Res_Set_Size_KB 1,874,672 1,867,516 1,874,684 1,872,888
> --------------------------------------------------------------------------------
> memcg_high 0 0 0 0
> memcg_swap_fail 0 0 0 0
> zswpout 114,742,930 112,836,725 92,904,961 89,596,085
> zswpin 41,184,897 39,983,793 31,018,149 29,163,932
> pswpout 625 1,069 558 1,059
> pswpin 599 1,056 540 1,051
> thp_swpout 1 2 1 2
> thp_swpout_fallback 10,967 10,195 6,918 6,141
> pgmajfault 42,588,331 41,349,069 31,931,882 30,006,422
> ZSWPOUT-2048kB 7,661 8,710 6,799 7,480
> SWPOUT-2048kB 1 2 1 2
> --------------------------------------------------------------------------------
>
>
> Sure, I will add a comment, and also "#include <linux/prefetch.h>" in zswap.c
> that will resolve the build error. This is similar to how these files handle prefetchw:
> mm/vmscan.c, kernel/locking/qspinlock.c, include/asm-generic/xor.h, etc.
Please also explicitly mention that the prefetch and likely/unlikely
annotations prevent regressions with software compression like zstd, and
generally improve the performance with the batching code by ~1.5%.
>
> Thanks,
> Kanchana
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios.
2025-03-06 21:20 ` Yosry Ahmed
@ 2025-04-30 21:07 ` Sridhar, Kanchana P
0 siblings, 0 replies; 5+ messages in thread
From: Sridhar, Kanchana P @ 2025-04-30 21:07 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Nhat Pham, lkp, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
hannes@cmpxchg.org, chengming.zhou@linux.dev,
usamaarif642@gmail.com, ryan.roberts@arm.com, 21cnbao@gmail.com,
ying.huang@linux.alibaba.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,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
Feghali, Wajdi K, Gopal, Vinodh, Sridhar, Kanchana P
> -----Original Message-----
> From: Yosry Ahmed <yosry.ahmed@linux.dev>
> Sent: Thursday, March 6, 2025 1:21 PM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: Nhat Pham <nphamcs@gmail.com>; lkp <lkp@intel.com>; linux-
> kernel@vger.kernel.org; linux-mm@kvack.org; hannes@cmpxchg.org;
> chengming.zhou@linux.dev; usamaarif642@gmail.com;
> ryan.roberts@arm.com; 21cnbao@gmail.com;
> ying.huang@linux.alibaba.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
> <kristen.c.accardi@intel.com>; llvm@lists.linux.dev; oe-kbuild-
> all@lists.linux.dev; Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal,
> Vinodh <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v8 14/14] mm: zswap: Compress batching with request
> chaining in zswap_store() of large folios.
>
> On Mon, Mar 03, 2025 at 09:34:04PM +0000, Sridhar, Kanchana P wrote:
> >
> > > -----Original Message-----
> > > From: Nhat Pham <nphamcs@gmail.com>
> > > Sent: Monday, March 3, 2025 10:22 AM
> > > To: lkp <lkp@intel.com>
> > > Cc: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>; 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; 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
> > > <kristen.c.accardi@intel.com>; llvm@lists.linux.dev; oe-kbuild-
> > > all@lists.linux.dev; Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal,
> > > Vinodh <vinodh.gopal@intel.com>
> > > Subject: Re: [PATCH v8 14/14] mm: zswap: Compress batching with
> request
> > > chaining in zswap_store() of large folios.
> > >
> > > On Mon, Mar 3, 2025 at 3:07 AM kernel test robot <lkp@intel.com>
> wrote:
> > > >
> > > > Hi Kanchana,
> > > >
> > > > kernel test robot noticed the following build errors:
> > > >
> > > > > 1166 prefetchw(entries[j]);
> > > > --
> > >
> > > Why are we doing this anyway? Does it have a notable performance
> > > difference? At the very least, leave a comment explaining why we're
> > > prefetching this (although the build error suggests that we have to
> > > remove it anyway).
> >
> > Hi Nhat,
> >
> > Yes, it does. The use of prefetchw reduces sys time by ~1.5% because
> > it minimizes cache-miss latency by moving the zswap entry to the cache
> > before it is written to.
> >
> > This is data with kernel compilation test, v8 without prefetchw and v8 as-is:
> >
> > --------------------------------------------------------------------------------
> > Kernel compile v8 without v8 v8 without v8
> > allmodconfig prefetchw prefetchw
> > 2M folios
> > --------------------------------------------------------------------------------
> > zswap compressor deflate-iaa deflate-iaa zstd zstd
> > --------------------------------------------------------------------------------
> > real_sec 732.89 735.63 768.53 758.21
> > user_sec 15,708.37 15,699.84 15,702.64 15,678.73
> > sys_sec 4,632.58 4,563.70 5,735.06 5,635.69
> > --------------------------------------------------------------------------------
> > Max_Res_Set_Size_KB 1,874,672 1,867,516 1,874,684
> 1,872,888
> > --------------------------------------------------------------------------------
> > memcg_high 0 0 0 0
> > memcg_swap_fail 0 0 0 0
> > zswpout 114,742,930 112,836,725 92,904,961 89,596,085
> > zswpin 41,184,897 39,983,793 31,018,149 29,163,932
> > pswpout 625 1,069 558 1,059
> > pswpin 599 1,056 540 1,051
> > thp_swpout 1 2 1 2
> > thp_swpout_fallback 10,967 10,195 6,918 6,141
> > pgmajfault 42,588,331 41,349,069 31,931,882 30,006,422
> > ZSWPOUT-2048kB 7,661 8,710 6,799 7,480
> > SWPOUT-2048kB 1 2 1 2
> > --------------------------------------------------------------------------------
> >
> >
> > Sure, I will add a comment, and also "#include <linux/prefetch.h>" in
> zswap.c
> > that will resolve the build error. This is similar to how these files handle
> prefetchw:
> > mm/vmscan.c, kernel/locking/qspinlock.c, include/asm-generic/xor.h, etc.
>
> Please also explicitly mention that the prefetch and likely/unlikely
> annotations prevent regressions with software compression like zstd, and
> generally improve the performance with the batching code by ~1.5%.
Yes, I have mentioned this in the comments and commit log. So also the
mutex locking.
>
> >
> > Thanks,
> > Kanchana
> >
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-04-30 21:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20250303084724.6490-15-kanchana.p.sridhar@intel.com>
2025-03-03 11:07 ` [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios kernel test robot
2025-03-03 18:21 ` Nhat Pham
2025-03-03 21:34 ` Sridhar, Kanchana P
2025-03-06 21:20 ` Yosry Ahmed
2025-04-30 21:07 ` Sridhar, Kanchana P
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox