| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <PH7PR11MB812141865845E36F05DD388FC9832@PH7PR11MB8121.namprd11.prod.outlook.com> Date: Wed, 30 Apr 2025 21:07:03 +0000 From: "Sridhar, Kanchana P" <kanchana.p.sridhar@...el.com> To: Yosry Ahmed <yosry.ahmed@...ux.dev> CC: Nhat Pham <nphamcs@...il.com>, lkp <lkp@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "hannes@...xchg.org" <hannes@...xchg.org>, "chengming.zhou@...ux.dev" <chengming.zhou@...ux.dev>, "usamaarif642@...il.com" <usamaarif642@...il.com>, "ryan.roberts@....com" <ryan.roberts@....com>, "21cnbao@...il.com" <21cnbao@...il.com>, "ying.huang@...ux.alibaba.com" <ying.huang@...ux.alibaba.com>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>, "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>, "davem@...emloft.net" <davem@...emloft.net>, "clabbe@...libre.com" <clabbe@...libre.com>, "ardb@...nel.org" <ardb@...nel.org>, "ebiggers@...gle.com" <ebiggers@...gle.com>, "surenb@...gle.com" <surenb@...gle.com>, "Accardi, Kristen C" <kristen.c.accardi@...el.com>, "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>, "oe-kbuild-all@...ts.linux.dev" <oe-kbuild-all@...ts.linux.dev>, "Feghali, Wajdi K" <wajdi.k.feghali@...el.com>, "Gopal, Vinodh" <vinodh.gopal@...el.com>, "Sridhar, Kanchana P" <kanchana.p.sridhar@...el.com> Subject: RE: [PATCH v8 14/14] mm: zswap: Compress batching with request chaining in zswap_store() of large folios. > -----Original Message----- > From: Yosry Ahmed <yosry.ahmed@...ux.dev> > Sent: Thursday, March 6, 2025 1:21 PM > To: Sridhar, Kanchana P <kanchana.p.sridhar@...el.com> > Cc: Nhat Pham <nphamcs@...il.com>; lkp <lkp@...el.com>; linux- > kernel@...r.kernel.org; linux-mm@...ck.org; hannes@...xchg.org; > chengming.zhou@...ux.dev; usamaarif642@...il.com; > ryan.roberts@....com; 21cnbao@...il.com; > ying.huang@...ux.alibaba.com; akpm@...ux-foundation.org; linux- > crypto@...r.kernel.org; herbert@...dor.apana.org.au; > davem@...emloft.net; clabbe@...libre.com; ardb@...nel.org; > ebiggers@...gle.com; surenb@...gle.com; Accardi, Kristen C > <kristen.c.accardi@...el.com>; llvm@...ts.linux.dev; oe-kbuild- > all@...ts.linux.dev; Feghali, Wajdi K <wajdi.k.feghali@...el.com>; Gopal, > Vinodh <vinodh.gopal@...el.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@...il.com> > > > Sent: Monday, March 3, 2025 10:22 AM > > > To: lkp <lkp@...el.com> > > > Cc: Sridhar, Kanchana P <kanchana.p.sridhar@...el.com>; linux- > > > kernel@...r.kernel.org; linux-mm@...ck.org; hannes@...xchg.org; > > > yosry.ahmed@...ux.dev; chengming.zhou@...ux.dev; > > > usamaarif642@...il.com; ryan.roberts@....com; 21cnbao@...il.com; > > > ying.huang@...ux.alibaba.com; akpm@...ux-foundation.org; linux- > > > crypto@...r.kernel.org; herbert@...dor.apana.org.au; > > > davem@...emloft.net; clabbe@...libre.com; ardb@...nel.org; > > > ebiggers@...gle.com; surenb@...gle.com; Accardi, Kristen C > > > <kristen.c.accardi@...el.com>; llvm@...ts.linux.dev; oe-kbuild- > > > all@...ts.linux.dev; Feghali, Wajdi K <wajdi.k.feghali@...el.com>; Gopal, > > > Vinodh <vinodh.gopal@...el.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@...el.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 > >
Powered by blists - more mailing lists