linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Nhat Pham <nphamcs@gmail.com>
Cc: Kanchana P Sridhar <kanchana.p.sridhar@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,
	ying.huang@intel.com,  21cnbao@gmail.com,
	akpm@linux-foundation.org, nanhai.zou@intel.com,
	 wajdi.k.feghali@intel.com, vinodh.gopal@intel.com
Subject: Re: [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios
Date: Thu, 29 Aug 2024 16:54:53 -0700	[thread overview]
Message-ID: <CAJD7tkbYufUeWWLh=WU1xgeVLMaoafPz+SHgtf+JtYWN+6PbHg@mail.gmail.com> (raw)
In-Reply-To: <CAKEwX=PXvLZ0GBgBbxSX5qvB-5dYuQ=5Z88UN3oGmNxFMnMtrg@mail.gmail.com>

On Thu, Aug 29, 2024 at 4:45 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Thu, Aug 29, 2024 at 3:49 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Thu, Aug 29, 2024 at 2:27 PM Kanchana P Sridhar
> >
> > We are basically comparing zram with zswap in this case, and it's not
> > fair because, as you mentioned, the zswap compressed data is being
> > accounted for while the zram compressed data isn't. I am not really
> > sure how valuable these test results are. Even if we remove the cgroup
> > accounting from zswap, we won't see an improvement, we should expect a
> > similar performance to zram.
> >
> > I think the test results that are really valuable are case 1, where
> > zswap users are currently disabling CONFIG_THP_SWAP, and get to enable
> > it after this series.
>
> Ah, this is a good point.
>
> I think the point of comparing mTHP zswap v.s mTHP (SSD)swap is more
> of a sanity check. IOW, if mTHP swap outperforms mTHP zswap, then
> something is wrong (otherwise why would enable zswap - might as well
> just use swap, since SSD swap with mTHP >>> zswap with mTHP >>> zswap
> without mTHP).

Yeah, good point, but as you mention below..

>
> That said, I don't think this benchmark can show it anyway. The access
> pattern here is such that all the allocated memories are really cold,
> so swap to disk (or to zram, which does not account memory usage
> towards cgroup) is better by definition... And Kanchana does not seem
> to have access to setup with larger SSD swapfiles? :)

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.


  reply	other threads:[~2024-08-29 23:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29 21:27 Kanchana P Sridhar
2024-08-29 21:27 ` [PATCH v6 1/3] mm: Define obj_cgroup_get() if CONFIG_MEMCG is not defined Kanchana P Sridhar
2024-08-29 21:27 ` [PATCH v6 2/3] mm: zswap: zswap_store() extended to handle mTHP folios Kanchana P Sridhar
2024-08-29 23:06   ` Yosry Ahmed
2024-09-20  1:57     ` Sridhar, Kanchana P
2024-09-02 11:37   ` Chengming Zhou
2024-09-20  2:43     ` Sridhar, Kanchana P
2024-09-16  5:55   ` Barry Song
2024-09-20 20:53     ` Sridhar, Kanchana P
2024-08-29 21:27 ` [PATCH v6 3/3] mm: swap: Count successful mTHP ZSWAP stores in sysfs mTHP zswpout stats Kanchana P Sridhar
2024-08-30  0:19   ` Nhat Pham
2024-09-20  2:32     ` Sridhar, Kanchana P
2024-09-20 22:57   ` Yosry Ahmed
2024-09-20 23:28     ` Sridhar, Kanchana P
2024-08-29 22:48 ` [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios Yosry Ahmed
2024-08-29 23:45   ` Nhat Pham
2024-08-29 23:54     ` Yosry Ahmed [this message]
2024-08-30  0:06       ` Nhat Pham
2024-08-30  0:14         ` Yosry Ahmed
2024-09-20  2:30           ` Sridhar, Kanchana P
2024-09-20  2:26         ` Sridhar, Kanchana P
2024-09-20  2:22       ` Sridhar, Kanchana P
2024-09-20  2:16     ` Sridhar, Kanchana P
2024-09-20  9:12       ` Huang, Ying
2024-09-20 16:53         ` Sridhar, Kanchana P
2024-08-30  9:27   ` Huang, Ying
2024-09-20  2:41     ` Sridhar, Kanchana P
2024-09-20  1:41   ` Sridhar, Kanchana P
2024-09-20  9:29     ` Huang, Ying
2024-09-20 17:57       ` Sridhar, Kanchana P
2024-09-20 23:15     ` Yosry Ahmed
2024-09-20 23:45       ` Sridhar, Kanchana P
2024-09-02 14:40 ` Usama Arif
2024-09-20 19:31   ` Sridhar, Kanchana P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJD7tkbYufUeWWLh=WU1xgeVLMaoafPz+SHgtf+JtYWN+6PbHg@mail.gmail.com' \
    --to=yosryahmed@google.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=kanchana.p.sridhar@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nanhai.zou@intel.com \
    --cc=nphamcs@gmail.com \
    --cc=ryan.roberts@arm.com \
    --cc=usamaarif642@gmail.com \
    --cc=vinodh.gopal@intel.com \
    --cc=wajdi.k.feghali@intel.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox