All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Francois Dugast <francois.dugast@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v2 6/6] drm/xe/svm: Migrate folios when possible
Date: Fri, 25 Jul 2025 16:14:17 -0700	[thread overview]
Message-ID: <aIQPyTnoaPEIA6zI@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20250725154011.2807655-7-francois.dugast@intel.com>

On Fri, Jul 25, 2025 at 05:39:30PM +0200, Francois Dugast wrote:
> The DMA mapping can now correspond to a folio (order > 0), so move the
> iterator by the number of pages in the folio in order to migrate all
> pages at once. This will improve efficiency compared to migrating pages
> one by one.
> 
> For this to work, the BOs must be contiguous in memory.
> 

I'd mention since SVM BOs are a max of 2M and it is very unlikely
forcing to continuous has any negative affects (e.g., extra eviction),
it greatly simplifies the code, and 2M contiguous memory will enable 2M
device pages which is huge perf win.

We might need a small adjustment to populate_devmem_pfn to communicate
contigous memory was found to drm_pagemap too as our driver can easily
allocate contiguous memory, but we shouldn't assume other drivers can
do so. This can be done in follow up which adds the 2M device page
support.

> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_bo.c  | 2 ++
>  drivers/gpu/drm/xe/xe_svm.c | 5 +++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index ffca1cea5585..59994a978a8c 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -200,6 +200,8 @@ static bool force_contiguous(u32 bo_flags)
>  	else if (bo_flags & XE_BO_FLAG_PINNED &&
>  		 !(bo_flags & XE_BO_FLAG_PINNED_LATE_RESTORE))
>  		return true; /* needs vmap */
> +	else if (bo_flags & XE_BO_FLAG_CPU_ADDR_MIRROR)
> +		return true;
>  
>  	/*
>  	 * For eviction / restore on suspend / resume objects pinned in VRAM
> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> index 1d097e76aabc..2759db5f7407 100644
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c
> @@ -382,6 +382,11 @@ static int xe_svm_copy(struct page **pages,
>  				pos = i;
>  			}
>  
> +			if (pagemap_addr[i].order) {
> +				i += NR_PAGES(pagemap_addr[i].order);

I think this needs to be NR_PAGES(pagemap_addr[i].order) - 1, right?

> +				last = (i + 1) == npages;

Then set the chunk here too?

> +			}
> +
>  			match = vram_addr + PAGE_SIZE * (i - pos) == __vram_addr;

I think the match can be dropped actually and just assume it is true if
we are allocating continuous memory now.

Matt

>  		}
>  
> -- 
> 2.43.0
> 

  reply	other threads:[~2025-07-25 23:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-25 15:39 [PATCH v2 0/6] Prepare GPU SVM for migration of THP Francois Dugast
2025-07-25 15:39 ` [PATCH v2 1/6] drm/pagemap: Rename drm_pagemap_device_addr to drm_pagemap_addr Francois Dugast
2025-07-25 21:46   ` Matthew Brost
2025-07-25 15:39 ` [PATCH v2 2/6] drm/pagemap: Use struct drm_pagemap_addr in mapping and copy functions Francois Dugast
2025-07-25 21:52   ` Matthew Brost
2025-07-25 15:39 ` [PATCH v2 3/6] drm/pagemap: DMA map folios when possible Francois Dugast
2025-07-25 21:54   ` Matthew Brost
2025-07-25 15:39 ` [PATCH v2 4/6] drm/pagemap: Allocate " Francois Dugast
2025-07-25 21:43   ` Matthew Brost
2025-07-28 10:18     ` Francois Dugast
2025-07-29  6:15       ` Matthew Brost
2025-07-25 15:39 ` [PATCH v2 5/6] drm/xe/migrate: Populate struct drm_pagemap_addr array Francois Dugast
2025-07-25 23:04   ` Matthew Brost
2025-07-25 15:39 ` [PATCH v2 6/6] drm/xe/svm: Migrate folios when possible Francois Dugast
2025-07-25 23:14   ` Matthew Brost [this message]
2025-07-28 14:10     ` Francois Dugast
2025-07-28 20:09       ` Matthew Brost
2025-07-28 21:15         ` Matthew Brost
2025-07-25 16:30 ` ✗ CI.checkpatch: warning for Prepare GPU SVM for migration of THP (rev2) Patchwork
2025-07-25 16:31 ` ✓ CI.KUnit: success " Patchwork
2025-07-25 17:29 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-25 19:02 ` ✗ Xe.CI.Full: failure " Patchwork

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=aIQPyTnoaPEIA6zI@lstrano-desk.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    /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.