RE: [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios

["Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>]

> -----Original Message-----
> From: Yosry Ahmed <yosryahmed@google.com>
> Sent: Friday, September 20, 2024 4:16 PM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> hannes@cmpxchg.org; nphamcs@gmail.com; chengming.zhou@linux.dev;
> usamaarif642@gmail.com; ryan.roberts@arm.com; Huang, Ying
> <ying.huang@intel.com>; 21cnbao@gmail.com; akpm@linux-foundation.org;
> Zou, Nanhai <nanhai.zou@intel.com>; Feghali, Wajdi K
> <wajdi.k.feghali@intel.com>; Gopal, Vinodh <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios
> 
> [..]
> > > If we really want to compare CONFIG_THP_SWAP on before and after, it
> > > should be with SSD because that's a more conventional setup. In this
> > > case the users that have CONFIG_THP_SWAP=y only experience the
> > > benefits of zswap with this series. You mentioned experimenting with
> > > usemem to keep the memory allocated longer so that you're able to have
> > > a fair test with the small SSD swap setup. Did that work?
> >
> > Thanks, these are good points. I ran this experiment with mm-unstable 9-
> 17-2024,
> > commit 248ba8004e76eb335d7e6079724c3ee89a011389.
> >
> > Data is based on average of 3 runs of the vm-scalability "usemem" test.
> 
> Thanks for the results, this makes much more sense. I see you also ran
> the tests with a larger swap size, which is good. In the next
> iteration, I would honestly drop the results with --sleep 0 because
> it's not a fair comparison imo.

Thanks for the comments, Yosry. Sure, this sounds good.

> 
> I see that in most cases we are observing higher sys time with zswap,
> and sometimes even higher elapsed time, which is concerning. If the
> sys time is higher when comparing zswap to SSD, but elapsed time is
> not higher, this can be normal due to compression on the CPU vs.
> asynchronous disk writes.
> 
> However, if the sys time increases when comparing CONFIG_THP_SWAP=n
> before this series and CONFIG_THP_SWAP=y with this series (i.e.
> comparing zswap with 4K vs. zswap with mTHP), then that's a problem.
> 
> Also, if the total elapsed time increases, it is also a problem.

Agreed. So far in the "Case 1" data published in v6, that compares zswap 4k
(CONFIG_THP_SWAP=n) vs. zswap mTHP (CONFIG_THP_SWAP=y), we see
consistent reduction in sys time with this patch-series. I will confirm by
re-gathering data with v7 (will post elapsed and sys times).

> 
> My main concern is that synchronous compression of an mTHP may be too
> expensive of an operation to do in one shot. I am wondering if we need
> to implement asynchronous swapout for zswap, so that it behaves more
> like swapping to disk from a reclaim perspective.
> 
> Anyway, there are too many test results now. For the next version, I
> would suggest only having two different test cases:
> 1. Comparing zswap 4K vs zswap mTHP. This would be done by comparing
> CONFIG_THP_SWAP=n to CONFIG_THP_SWAP=y as you did before.
> 
> 2. Comparing SSD swap mTHP vs zswap mTHP.
> 
> In both cases, I think we want to use a sufficiently large swapfile
> and make the usemem processes sleep for a while to maintain the memory
> allocations. Since we already confirmed the theory about the
> restricted swapfile results being due to processes immediately
> exiting, I don't see value in running tests anymore with a restricted
> swapfile or without sleeping.

Ok, this sounds good. I will submit a v7 with all these suggestions incorporated.

Thanks,
Kanchana

> 
> Thanks!