linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Peter Xu <peterx@redhat.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm: Remove stub for non_swap_entry()
Date: Thu, 14 Apr 2022 15:48:33 +1000	[thread overview]
Message-ID: <87zgko9obm.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <20220413191147.66645-1-peterx@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

Peter Xu <peterx@redhat.com> writes:

> The stub for non_swap_entry() may not help much, because MAX_SWAPFILES has
> already contained all the information to decide whether a swap entry is
> real swap entry of pesudo ones (migrations, ...).
>
> There can be some performance influences on non_swap_entry() with below
> conditions all met:
>
>   !CONFIG_MIGRATION && !CONFIG_MEMORY_FAILURE && !CONFIG_DEVICE_PRIVATE
>
> But that's definitely not the major config most machines will use, at the
> meantime it's already in a slow path of swap entry (being parsed from a
> swap pte), so IMHO it shouldn't be a major issue.  Also according to the
> analysis from Alistair, somehow the stub didn't do the job right [1].

I wasn't so much concerned about execution speed given it's on the slow path
anyway but overall code size, which is one reason all those config options might
be disabled. However in practice it made little to no difference as those config
options already remove most of the extra code so I agree we can drop the stub.

Reviewed-by: Alistair Popple <apopple@nvidia.com>

> To make the code cleaner, let's drop the stub.
>
> [1] <https://lore.kernel.org/lkml/8735ihbw6g.fsf@nvdebian.thelocal/>
>
> Cc: Alistair Popple <apopple@nvidia.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>
> Note: the uffd-wp shmem & hugetlbfs series will need this patch to make
> sure swap entries work as expected with below config as spotted by
> Alistair:
>
>   !CONFIG_MIGRATION &&
>   !CONFIG_MEMORY_FAILURE &&
>   !CONFIG_DEVICE_PRIVATE &&
>   CONFIG_PTE_MARKER
>
> (PS: this config should mostly never gonna happen, though, afaict..)
>
> Quoting the same thread [1] as above.
>
> Please review, thanks.
> ---
>  include/linux/swapops.h | 8 --------
>  1 file changed, 8 deletions(-)
>
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index fffbba0036f6..a291f210e7f8 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -493,18 +493,10 @@ static inline void num_poisoned_pages_inc(void)
>  }
>  #endif
>
> -#if defined(CONFIG_MEMORY_FAILURE) || defined(CONFIG_MIGRATION) || \
> -    defined(CONFIG_DEVICE_PRIVATE)
>  static inline int non_swap_entry(swp_entry_t entry)
>  {
>  	return swp_type(entry) >= MAX_SWAPFILES;
>  }
> -#else
> -static inline int non_swap_entry(swp_entry_t entry)
> -{
> -	return 0;
> -}
> -#endif
>
>  #endif /* CONFIG_MMU */
>  #endif /* _LINUX_SWAPOPS_H */

  reply	other threads:[~2022-04-14  6:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 19:11 Peter Xu
2022-04-14  5:48 ` Alistair Popple [this message]
2022-04-14 14:21   ` Peter Xu

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=87zgko9obm.fsf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.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