linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jordan Niethe <jniethe@nvidia.com>
To: linux-mm@kvack.org
Cc: balbirs@nvidia.com, matthew.brost@intel.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, david@redhat.com,
	ziy@nvidia.com, apopple@nvidia.com, lorenzo.stoakes@oracle.com,
	lyude@redhat.com, dakr@kernel.org, airlied@gmail.com,
	simona@ffwll.ch, rcampbell@nvidia.com, mpenttil@redhat.com,
	jgg@nvidia.com, willy@infradead.org,
	linuxppc-dev@lists.ozlabs.org, intel-xe@lists.freedesktop.org,
	jgg@ziepe.ca, Felix.Kuehling@amd.com
Subject: Re: [PATCH v2 07/11] mm: Add a new swap type for migration entries of device private pages
Date: Mon, 12 Jan 2026 12:00:07 +1100	[thread overview]
Message-ID: <375f5d20-7c15-4f8e-a9cd-c58e3e398c62@nvidia.com> (raw)
In-Reply-To: <20260107091823.68974-8-jniethe@nvidia.com>

Hi,

I am copying across this discussion that occurred on a resend of this 
series on the intel-xe list for a wider audience [0].

[0] 
https://lore.kernel.org/all/8bf680f0-94ed-4614-9ace-a081a6558460@nvidia.com/

On 9/1/26 06:08, Lorenzo Stoakes wrote:

 >> @@ -28,6 +28,9 @@ enum softleaf_type {
 >>       SOFTLEAF_DEVICE_PRIVATE_READ,
 >>       SOFTLEAF_DEVICE_PRIVATE_WRITE,
 >>       SOFTLEAF_DEVICE_EXCLUSIVE,
 >> +    SOFTLEAF_MIGRATION_DEVICE_READ,
 >> +    SOFTLEAF_MIGRATION_DEVICE_READ_EXCLUSIVE,
 >> +    SOFTLEAF_MIGRATION_DEVICE_WRITE,
 >
 > I think these should be SOFTLEAF_MIGRATION_DEVICE_PRIVATE_xxx
 >
 > And I realise that's a mouthful 🙂
 >
 > But to be consistent with other naming, including 
SOFTLEAF_DEVICE_PRIVATE_*.

Sure.

 >
 >
 > I don't see any users of this, do you definitely use it? I mean 
presumably you
 > might in a subsequent patch, not checked.
 >
 > Otherwise I'd wrap it into softleaf_is_migration().

It gets used in the final patch of the series when we begin doing things 
like:

static inline struct page *softleaf_to_page(softleaf_t entry)
{
     struct page *page;

     if (softleaf_is_migration_device_private(entry) ||
         softleaf_is_device_private(entry))
         page = device_private_entry_to_page(entry);
     else
         page = pfn_to_page(softleaf_to_pfn(entry));


 >
 >>
 >>   /**
 >> @@ -211,7 +279,8 @@ static inline bool 
softleaf_is_migration_write(softleaf_t entry)
 >>    */
 >>   static inline bool softleaf_is_migration_read(softleaf_t entry)
 >>   {
 >
 > For these ones that you are making sort of compound now, can you 
please update
 > the kdoc to reflect it? You've done it for others but not this one.
 >

Sure, sorry I missed this one.

 >> -    return softleaf_type(entry) == SOFTLEAF_MIGRATION_READ;
 >> +    return softleaf_type(entry) == SOFTLEAF_MIGRATION_READ ||
 >> +           softleaf_is_migration_device_private_read(entry);
 >>   }
 >>
 >>   /**
 >> @@ -219,12 +288,13 @@ static inline bool 
softleaf_is_migration_read(softleaf_t entry)
 >>    * readable migration entry?
 >>    * @entry: Leaf entry.
 >>    *
 >> - * Returns: true if the leaf entry is an exclusive readable 
migration entry,
 >> - * otherwise false.
 >> + * Returns: true if the leaf entry is an exclusive readable 
migration entry or
 >> + * exclusive readable device private migration entry, otherwise false.
 >>    */
 >>   static inline bool softleaf_is_migration_read_exclusive(softleaf_t 
entry)
 >>   {
 >> -    return softleaf_type(entry) == SOFTLEAF_MIGRATION_READ_EXCLUSIVE;
 >> +    return softleaf_type(entry) == SOFTLEAF_MIGRATION_READ_EXCLUSIVE ||
 >> +           softleaf_is_migration_device_private_read_exclusive(entry);
 >>   }
 >>
 >>   /**
 >> @@ -241,7 +311,7 @@ static inline bool 
softleaf_is_migration(softleaf_t entry)
 >>       case SOFTLEAF_MIGRATION_WRITE:
 >>           return true;
 >>       default:
 >> -        return false;
 >> +        return softleaf_is_migration_device_private(entry);
 >>       }
 >>   }
 >
 > So all of these above ^^^ are making it so you can't determine if an 
entry is
 > 'migration xxx' vs. 'migration xxx device private'. Is this ok?
 >
 > Does anything need to exclusively determine if something is a 'migration
 > xxx'?
 >
 > If not then fine, but just wanted to check.

The new entry types have the following relationship:

SOFTLEAF_MIGRATION_DEVICE_READ is-a SOFTLEAF_MIGRATION_READ
SOFTLEAF_MIGRATION_READ !is-a SOFTLEAF_MIGRATION_DEVICE_READ

So it is remains possible the distinguish the types using the
softleaf_is_migration_device_private_read() check

In practice, the only reason for introducing this new type is so we know 
when
we can not call pfn_to_page() on the swap entry offset. That is the only 
time
that the difference matters.

Rather than introducing a new type we could accomplish this by adding a new
flag like SWP_MIG_DIRTY, SWP_MIG_YOUNG but my concern was how we handle the
!migration_entry_supports_ad() case.


 >
 >>
 >> diff --git a/include/linux/swap.h b/include/linux/swap.h
 >> index 38ca3df68716..c15e3b3067cd 100644
 >> --- a/include/linux/swap.h
 >> +++ b/include/linux/swap.h
 >> @@ -74,12 +74,18 @@ static inline int current_is_kswapd(void)
 >>    *
 >>    * When a page is mapped by the device for exclusive access we set 
the CPU page
 >>    * table entries to a special SWP_DEVICE_EXCLUSIVE entry.
 >> + *
 >> + * Because device private pages do not use regular PFNs, special 
migration
 >> + * entries are also needed.
 >>    */
 >>   #ifdef CONFIG_DEVICE_PRIVATE
 >> -#define SWP_DEVICE_NUM 3
 >> +#define SWP_DEVICE_NUM 6
 >>   #define SWP_DEVICE_WRITE 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM)
 >>   #define SWP_DEVICE_READ 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+1)
 >>   #define SWP_DEVICE_EXCLUSIVE 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+2)
 >> +#define SWP_MIGRATION_DEVICE_READ 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+3)
 >> +#define SWP_MIGRATION_DEVICE_READ_EXCLUSIVE 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+4)
 >> +#define SWP_MIGRATION_DEVICE_WRITE 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+5)
 >
 > I've lost track on how many entries we have left, have you tested 
this with a
 > config that maximises the number?

Good point - let me double check that.

 >
 > I really hate how we do this by the way, that's another thing to 
fix... 🙂
 >
 >>   #else
 >>   #define SWP_DEVICE_NUM 0
 >>   #endif
 >> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
 >> index a9ad997bd5ec..bae76d3831fb 100644
 >> --- a/include/linux/swapops.h
 >> +++ b/include/linux/swapops.h
 >
 > Since this is pure softleaf stuff can we please put it all in 
leafops.h if
 > possible? I know we already have some stuff here rather than there, 
but this
 > really doesn't seem to belong here.

The reason for adding the swapops.h entries to correspond with the softleaf
entries was it looked like the swapops were still required for making
the entries currently.

That is, there aren't softleaf equivalents to
make_readable_device_private_entry() and friends yet.

Would it be better if I introduced the swapops.h changes in a proceeding 
patch?

 >
 >
 > Cheers, Lorenzo

Thanks for reviewing.

Jordan.


  reply	other threads:[~2026-01-12  1:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-07  9:18 [PATCH v2 00/11] Remove device private pages from physical address space Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 01/11] mm/migrate_device: Introduce migrate_pfn_from_page() helper Jordan Niethe
2026-01-08 20:03   ` Felix Kuehling
2026-01-08 23:49     ` Jordan Niethe
2026-01-09 21:03       ` Kuehling, Felix
2026-01-09 22:47   ` Balbir Singh
2026-01-07  9:18 ` [PATCH v2 02/11] drm/amdkfd: Use migrate pfns internally Jordan Niethe
2026-01-08 22:00   ` Felix Kuehling
2026-01-08 23:56     ` Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 03/11] mm/migrate_device: Make migrate_device_{pfns,range}() take mpfns Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 04/11] mm/migrate_device: Add migrate PFN flag to track device private pages Jordan Niethe
2026-01-08 20:01   ` Felix Kuehling
2026-01-08 23:41     ` Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 05/11] mm/page_vma_mapped: Add flags to page_vma_mapped_walk::pfn " Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 06/11] mm: Add helpers to create migration entries from struct pages Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 07/11] mm: Add a new swap type for migration entries of device private pages Jordan Niethe
2026-01-12  1:00   ` Jordan Niethe [this message]
2026-01-07  9:18 ` [PATCH v2 08/11] mm: Add helpers to create device private entries from struct pages Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 09/11] mm/util: Add flag to track device private pages in page snapshots Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 10/11] mm/hmm: Add flag to track device private pages Jordan Niethe
2026-01-07  9:18 ` [PATCH v2 11/11] mm: Remove device private pages from the physical address space Jordan Niethe
2026-01-07 18:36 ` [PATCH v2 00/11] Remove device private pages from " Matthew Brost
2026-01-07 20:21   ` Zi Yan
2026-01-08  2:25   ` Jordan Niethe
2026-01-08  5:42     ` Jordan Niethe
2026-01-09  0:01       ` Jordan Niethe
2026-01-09  0:31         ` Matthew Brost
2026-01-09  1:27           ` Jordan Niethe
2026-01-09  6:22             ` Matthew Brost
2026-01-07 20:06 ` Andrew Morton
2026-01-07 20:54   ` Jason Gunthorpe
2026-01-07 21:02     ` Balbir Singh
2026-01-08  1:29       ` Alistair Popple
2026-01-08  1:08   ` John Hubbard
2026-01-08  1:49   ` Alistair Popple
2026-01-08  2:55     ` Jordan Niethe

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=375f5d20-7c15-4f8e-a9cd-c58e3e398c62@nvidia.com \
    --to=jniethe@nvidia.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=david@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=lyude@redhat.com \
    --cc=matthew.brost@intel.com \
    --cc=mpenttil@redhat.com \
    --cc=rcampbell@nvidia.com \
    --cc=simona@ffwll.ch \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.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