linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chris Li <chrisl@kernel.org>
To: Nhat Pham <nphamcs@gmail.com>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org,
	yosryahmed@google.com,  hughd@google.com, shakeel.butt@linux.dev,
	ryan.roberts@arm.com,  ying.huang@intel.com, david@redhat.com,
	kasong@tencent.com,  willy@infradead.org,
	viro@zeniv.linux.org.uk, baohua@kernel.org,
	 chengming.zhou@linux.dev, linux-mm@kvack.org,
	kernel-team@meta.com,  linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM
Date: Tue, 24 Sep 2024 13:15:47 -0700	[thread overview]
Message-ID: <CACePvbV+iaqKGGy46xa3CJQvKsay_aw3w4nqs6rESW6Cu8T-Lg@mail.gmail.com> (raw)
In-Reply-To: <20240923231142.4155415-1-nphamcs@gmail.com>

Hi Nhat,

On Mon, Sep 23, 2024 at 4:11 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> The SWAP_MAP_SHMEM state was originally introduced in the commit
> aaa468653b4a ("swap_info: note SWAP_MAP_SHMEM"), to quickly determine if a
> swap entry belongs to shmem during swapoff.
>
> However, swapoff has since been rewritten drastically in the commit
> b56a2d8af914 ("mm: rid swapoff of quadratic complexity"). Now
> having swap count == SWAP_MAP_SHMEM value is basically the same as having
> swap count == 1, and swap_shmem_alloc() behaves analogously to
> swap_duplicate()
>
> This RFC proposes the removal of this state and the associated helper to
> simplify the state machine (both mentally and code-wise). We will also
> have an extra state/special value that can be repurposed (for swap entries
> that never gets re-duplicated).

Please help me understand. After having this patch, the shmem swap
entry will also use the swap continue as the only way to count shmem
swap entries, am I missing something?

That seems to have some performance hit for the shmem. Because unlike
anonymous memory, The shmem can easily have a very high swap count.
I would expect there to be some performance hit for the high share
swap count usage case.
Do you have any test number on high shared swap count usage that says
it is negligible to remove it?

Also if you remove the  in the SWAP_MAP_SHMEM, wouldn't you need
remove the counter in the shmem as well. Because the shmem counter is
no longer connected to the swap count any more.

Huge, do you have any feedback on this change?

Chris


> Another motivation (albeit a bit premature at the moment) is the new swap
> abstraction I am currently working on, that would allow for swap/zswap
> decoupling, swapoff optimization, etc. The fewer states and swap API
> functions there are, the simpler the conversion will be.
>
> I am sending this series first as an RFC, just in case I missed something
> or misunderstood this state, or if someone has a swap optimization in mind
> for shmem that would require this special state.
>
> Swap experts, let me know if I'm mistaken :) Otherwise if there is no
> objection I will resend this patch series again for merging.
>
> Nhat Pham (2):
>   swapfile: add a batched variant for swap_duplicate()
>   swap: shmem: remove SWAP_MAP_SHMEM
>
>  include/linux/swap.h | 16 ++++++++--------
>  mm/shmem.c           |  2 +-
>  mm/swapfile.c        | 28 +++++++++-------------------
>  3 files changed, 18 insertions(+), 28 deletions(-)
>
>
> base-commit: acfabf7e197f7a5bedf4749dac1f39551417b049
> --
> 2.43.5


  parent reply	other threads:[~2024-09-24 20:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-23 23:11 Nhat Pham
2024-09-23 23:11 ` [RFC PATCH 1/2] swapfile: add a batched variant for swap_duplicate() Nhat Pham
2024-09-23 23:11 ` [RFC PATCH 2/2] swap: shmem: remove SWAP_MAP_SHMEM Nhat Pham
2024-09-24  0:32   ` Yosry Ahmed
2024-09-24  0:20 ` [RFC PATCH 0/2] " Yosry Ahmed
2024-09-24  1:55 ` Baolin Wang
2024-09-24  2:15   ` Yosry Ahmed
2024-09-24  3:25     ` Baolin Wang
2024-09-24 14:32       ` Nhat Pham
2024-09-24 15:07         ` Yosry Ahmed
2024-09-24 15:48           ` Nhat Pham
2024-09-24 18:11             ` Yosry Ahmed
2024-09-25  6:26               ` Barry Song
2024-09-25  7:24                 ` Huang, Ying
2024-09-25  7:38                   ` Barry Song
2024-09-25  1:53             ` Baolin Wang
2024-09-25 14:37               ` Nhat Pham
2024-09-26  1:59                 ` Huang, Ying
2024-09-26  3:30                   ` Baolin Wang
2024-09-26  3:59                 ` Barry Song
2024-09-26 22:50                   ` Nhat Pham
2024-09-26  4:00                 ` Barry Song
2024-09-25  7:19             ` Huang, Ying
2024-09-25  7:32               ` Barry Song
2024-09-25 14:21                 ` Nhat Pham
2024-09-25 14:24                   ` Nhat Pham
2024-09-25 14:28                   ` Nhat Pham
2024-09-24 20:15 ` Chris Li [this message]
2024-09-24 21:30   ` 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=CACePvbV+iaqKGGy46xa3CJQvKsay_aw3w4nqs6rESW6Cu8T-Lg@mail.gmail.com \
    --to=chrisl@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=chengming.zhou@linux.dev \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kasong@tencent.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --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