From: Nhat Pham <nphamcs@gmail.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org,
shakeel.butt@linux.dev, linux-mm@kvack.org,
kernel-team@meta.com, linux-kernel@vger.kernel.org,
flintglass@gmail.com, chengming.zhou@linux.dev
Subject: Re: [PATCH v2 2/2] zswap: increment swapin count for non-pivot swapped in pages
Date: Fri, 2 Aug 2024 16:46:21 -0700 [thread overview]
Message-ID: <CAKEwX=PZy8FdBajsW3ai4CSrXfNzR5zAq28KwUVt92V4KgYtag@mail.gmail.com> (raw)
In-Reply-To: <CAJD7tkbQMB1RBr1mDb_Ye+wvk97mD1D-+uFAxOEw0ZRLZp1yRQ@mail.gmail.com>
On Thu, Aug 1, 2024 at 1:02 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
>
> Hmm, but there is a chance that these pages are not actually needed,
> in which case we will unnecessarily increase the zswap protection.
> Does the readahead window self-correct if the pages were not used?
Hmm yeah it's kinda hard to predict if a swapped in page is strictly
necessary in this context. We don't have this information at the time
of the read.
That said, I think erring on the side of safety is OK here - my
understanding that readahead, while predictive in nature, only gets
progressively more aggressive if we get signals that it's helpful (i.e
the memory access patterns display sequential behavior).
I think we also accept this slight inaccuracy (i.e for pages in the
readahead window that might not necessarily be needed) the in
workingset refault handling behavior. Could you fact check me,
Johannes?
>
> > are also incrementing when the pages are read from the zswap pool, which
> > is inaccurate.
>
> I feel like this is the more important part. It should be the focus of
> the commit log with more details (i.e. why is it wrong to increment
> the zswap protection in this case).
Yeah this is pretty important too :) Maybe I should make it clearer in
the patch commit.
>
> Do we need a Fixes and cc:stable for this one? Maybe it can be moved
> first to make backports easy.
Hmm.
*Technically*, this is broken in older versions of the shrinker as
well, but it's more of an optimization than a bug that can crash the
kernel, so I don't know if it qualifies for a Fixes tag?
Another factor is, under the old scheme, this does not move the needle
much - at least in my benchmarks. This is because the decaying
behavior is so aggressive that incrementing the counter in a couple
places does not matter, when it will be rapidly divided by half later.
This fix only shows clear improvements when applied on top of the new
second chance scheme.
I don't have a strong opinion here, but it doesn't seem worth it to
backport IMHO :)
next prev parent reply other threads:[~2024-08-02 23:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 22:27 [PATCH v2 0/2] improving dynamic zswap shrinker protection scheme Nhat Pham
2024-07-30 22:27 ` [PATCH v2 1/2] zswap: implement a second chance algorithm for dynamic zswap shrinker Nhat Pham
2024-07-30 22:47 ` [PATCH v2 1/2] zswap: implement a second chance algorithm for dynamic zswap shrinker (fix) Nhat Pham
2024-08-01 19:57 ` [PATCH v2 1/2] zswap: implement a second chance algorithm for dynamic zswap shrinker Yosry Ahmed
2024-08-05 23:11 ` Nhat Pham
2024-08-05 23:58 ` Yosry Ahmed
2024-07-30 22:27 ` [PATCH v2 2/2] zswap: increment swapin count for non-pivot swapped in pages Nhat Pham
2024-08-01 20:02 ` Yosry Ahmed
2024-08-02 23:46 ` Nhat Pham [this message]
2024-08-03 3:22 ` Yosry Ahmed
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='CAKEwX=PZy8FdBajsW3ai4CSrXfNzR5zAq28KwUVt92V4KgYtag@mail.gmail.com' \
--to=nphamcs@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=flintglass@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shakeel.butt@linux.dev \
--cc=yosryahmed@google.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