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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8oRsGHmt2E4diKK@google.com>
Date: Thu, 6 Mar 2025 21:20:48 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
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-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>
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%.

> 
> Thanks,
> Kanchana
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ