All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Peter Xu <peterx@redhat.com>
Cc: Nadav Amit <nadav.amit@gmail.com>, Linux MM <linux-mm@kvack.org>,
	linux-kernel@vger.kernel.org,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>, Hugh Dickins <hughd@google.com>,
	Andi Kleen <andi.kleen@intel.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v2 2/2] mm: Remember young/dirty bit for page migrations
Date: Tue, 09 Aug 2022 16:45:32 +0800	[thread overview]
Message-ID: <8735e5hkk3.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <Yu1FkCkjJ00+H0sF@xz-m1.local> (Peter Xu's message of "Fri, 5 Aug 2022 12:30:08 -0400")

Peter Xu <peterx@redhat.com> writes:

> On Thu, Aug 04, 2022 at 03:40:57PM -0700, Nadav Amit wrote:
>> On Aug 4, 2022, at 1:39 PM, Peter Xu <peterx@redhat.com> wrote:
>> > +
>> > static inline bool is_pfn_swap_entry(swp_entry_t entry);
>> > 
>> > /* Clear all flags but only keep swp_entry_t related information */
>> > @@ -265,6 +285,57 @@ static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
>> > 	return swp_entry(SWP_MIGRATION_WRITE, offset);
>> > }
>> > 
>> > +/*
>> > + * Returns whether the host has large enough swap offset field to support
>> > + * carrying over pgtable A/D bits for page migrations.  The result is
>> > + * pretty much arch specific.
>> > + */
>> > +static inline bool migration_entry_supports_ad(void)
>> > +{
>> > +	/*
>> > +	 * max_swapfile_size() returns the max supported swp-offset plus 1.
>> > +	 * We can support the migration A/D bits iff the pfn swap entry has
>> > +	 * the offset large enough to cover all of them (PFN, A & D bits).
>> > +	 */
>> > +#ifdef CONFIG_SWAP
>> > +	return max_swapfile_size() >= (1UL << SWP_MIG_TOTAL_BITS);
>> 
>> This is an actual a function call (unless LTO has some trick). A bit of a
>> shame it cannot be at least memoized.
>> 
>> Or at least mark max_swapfile_size() as __attribute_const__ so it would not
>> be called twice for make_migration_entry_young() and
>> make_migration_entry_dirty().
>
> I didn't take too much effort on this one since we're on swap path and I
> assumed that's not a super hot path.  But __attribute_const__ sounds good
> and easy to get, thanks.
>
> Perhaps I should mark it on migration_entry_supports_ad() as a whole?  Note
> that unfortunately SWP_MIG_TOTAL_BITS may not be a const either (see how
> that define roots back to MAX_PHYSMEM_BITS, where on x86_64 it needs to
> check 5-lvl).

I think it's possible to memorize max_swapfile_size() or
migration_entry_supports_ad().  Although they are not constant, they are
not changed after initialized.  The challenge is to find a clean way to
initialize it.

Best Regards,
Huang, Ying

  reply	other threads:[~2022-08-09  8:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 20:39 [PATCH v2 0/2] mm: Remember a/d bits for migration entries Peter Xu
2022-08-04 20:39 ` [PATCH v2 1/2] mm/swap: Add swp_offset_pfn() to fetch PFN from swap entry Peter Xu
2022-08-04 20:39 ` [PATCH v2 2/2] mm: Remember young/dirty bit for page migrations Peter Xu
2022-08-04 22:40   ` Nadav Amit
2022-08-05 16:30     ` Peter Xu
2022-08-09  8:45       ` Huang, Ying [this message]
2022-08-09  8:47         ` David Hildenbrand
2022-08-09 14:59         ` Peter Xu
2022-08-05 12:17   ` David Hildenbrand
2022-08-05 16:36     ` Peter Xu
2022-08-09  8:40   ` Huang, Ying
2022-08-09 17:59     ` Peter Xu
2022-08-10  0:53       ` Huang, Ying
2022-08-10 19:21         ` Peter Xu
2022-08-11  5:44           ` Alistair Popple
2022-08-04 22:17 ` [PATCH v2 0/2] mm: Remember a/d bits for migration entries Nadav Amit

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=8735e5hkk3.fsf@yhuang6-desk2.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=peterx@redhat.com \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.