> -----Original Message----- > From: Yosry Ahmed <yosryahmed@xxxxxxxxxx> > Sent: Thursday, August 29, 2024 5:14 PM > To: Nhat Pham <nphamcs@xxxxxxxxx> > Cc: Sridhar, Kanchana P <kanchana.p.sridhar@xxxxxxxxx>; linux- > kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; hannes@xxxxxxxxxxx; > chengming.zhou@xxxxxxxxx; usamaarif642@xxxxxxxxx; > ryan.roberts@xxxxxxx; Huang, Ying <ying.huang@xxxxxxxxx>; > 21cnbao@xxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; Zou, Nanhai > <nanhai.zou@xxxxxxxxx>; Feghali, Wajdi K <wajdi.k.feghali@xxxxxxxxx>; > Gopal, Vinodh <vinodh.gopal@xxxxxxxxx> > Subject: Re: [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios > > On Thu, Aug 29, 2024 at 5:06 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > > > On Thu, Aug 29, 2024 at 4:55 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> > wrote: > > > > > > On Thu, Aug 29, 2024 at 4:45 PM Nhat Pham <nphamcs@xxxxxxxxx> > wrote: > > > I think it's also the fact that the processes exit right after they > > > are done allocating the memory. So I think in the case of SSD, when we > > > stall waiting for IO some processes get to exit and free up memory, so > > > we need to do less swapping out in general because the processes are > > > more serialized. With zswap, all processes try to access memory at the > > > same time so the required amount of memory at any given point is > > > higher, leading to more thrashing. > > > > > > I suggested keeping the memory allocated for a long time to even the > > > playing field, or we can make the processes keep looping and accessing > > > the memory (or part of it) for a while. > > > > > > That being said, I think this may be a signal that the memory.high > > > throttling is not performing as expected in the zswap case. Not sure > > > tbh, but I don't think SSD swap should perform better than zswap in > > > that case. > > > > Yeah something is fishy there. That said, the benchmarking in v4 is wack: > > > > 1. We use lz4, which has a really poor compression factor. > > > > 2. The swapfile is really small, so we occasionally see problems with > > swap allocation failure. > > > > Both of these factors affect benchmarking validity and stability a > > lot. I think in this version's benchmarks, with zstd as the software > > compressor + a much larger swapfile (albeit on top of a ZRAM block > > device), we no longer see memory.high violation, even at a lower > > memory.high value...? The performance number is wack indeed - not a > > lot of values in the case 2 section. > > But when we use zram we are essentially comparing two swap mechanisms > compressing mTHPs page by page, with the only difference being that > zram does not account the memory. For this to have any value imo it > should be on an SSD to at least provide the value of being a practical > sanity check as you mentioned earlier. In its current form I don't > think it's providing any value. Just posted data today with SSD and longer running usemem processes, that should hopefully better quantify the benefit of zswap-mTHP. Thanks, Kanchana
