Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Brian Nguyen <brian3.nguyen@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <tejas.upadhyay@intel.com>,
	<shuicheng.lin@intel.com>, <stuart.summers@intel.com>
Subject: Re: [PATCH 07/11] drm/xe: Suballocate BO for page reclaim
Date: Sat, 22 Nov 2025 11:42:41 -0800	[thread overview]
Message-ID: <aSISMU58l2MPAFcd@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20251118090552.246243-8-brian3.nguyen@intel.com>

On Tue, Nov 18, 2025 at 05:05:48PM +0800, Brian Nguyen wrote:
> Page reclamation feature needs the PRL to be suballocated into a
> GGTT-mapped BO. On allocation failure, fallback to default tlb
> invalidation with full PPC flush.
> 
> PRL's BO allocation is managed in separate pool to ensure 4K alignment
> for proper GGTT address.
> 
> With BO, pass into TLB invalidation backend and modify fence to
> accomadate accordingly.
> 
> Signed-off-by: Brian Nguyen <brian3.nguyen@intel.com>
> Suggested-by: Matthew Brost <matthew.brost@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_device_types.h    |  7 ++++++
>  drivers/gpu/drm/xe/xe_page_reclaim.c    | 33 +++++++++++++++++++++++++
>  drivers/gpu/drm/xe/xe_page_reclaim.h    |  4 +++
>  drivers/gpu/drm/xe/xe_tile.c            |  5 ++++
>  drivers/gpu/drm/xe/xe_tlb_inval.c       | 18 ++++++++++++--
>  drivers/gpu/drm/xe/xe_tlb_inval_types.h |  5 ++++
>  6 files changed, 70 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
> index 268c8e28601a..057df3f9dc1d 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -184,6 +184,13 @@ struct xe_tile {
>  		 * Media GT shares a pool with its primary GT.
>  		 */
>  		struct xe_sa_manager *kernel_bb_pool;
> +
> +		/**
> +		 * @mem.reclaim_pool: Pool for PRLs allocated.
> +		 *
> +		 * Only main GT has page reclaim list allocations.
> +		 */
> +		struct xe_sa_manager *reclaim_pool;
>  	} mem;
>  
>  	/** @sriov: tile level virtualization data */
> diff --git a/drivers/gpu/drm/xe/xe_page_reclaim.c b/drivers/gpu/drm/xe/xe_page_reclaim.c
> index a0d15efff58c..801a7f1731c0 100644
> --- a/drivers/gpu/drm/xe/xe_page_reclaim.c
> +++ b/drivers/gpu/drm/xe/xe_page_reclaim.c
> @@ -13,6 +13,39 @@
>  #include "regs/xe_gt_regs.h"
>  #include "xe_assert.h"
>  #include "xe_macros.h"
> +#include "xe_sa.h"
> +#include "xe_tlb_inval_types.h"
> +
> +/**
> + * xe_page_reclaim_create_prl_bo() - Back a PRL with a suballocated GGTT BO
> + * @tlb_inval: TLB invalidation frontend associated with the request
> + * @fence: Fence carrying the PRL metadata
> + *
> + * Suballocates a 4K BO out of the tile reclaim pool, copies the PRL CPU
> + * copy into the BO and queues the buffer for release when @fence signals.
> + *
> + * Return: 0 on success or -ENOMEM if the suballocation fails.
> + */
> +int xe_page_reclaim_create_prl_bo(struct xe_tlb_inval *tlb_inval, struct xe_tlb_inval_fence *fence)

As discussed here [1] let's try to avoid storing anything in related to
PRL in "struct xe_tlb_inval_fence". So I think reclaim_entries + number
entries should be argumen to this function and return "struct
drm_subaloc*) or ERR_PTR here.

[1] https://patchwork.freedesktop.org/patch/689042/?series=157698&rev=1#comment_1267062

> +{
> +	struct xe_gt *gt = container_of(tlb_inval, struct xe_gt, tlb_inval);
> +	struct xe_tile *tile = gt_to_tile(gt);
> +
> +	/* Maximum size of PRL is 1 4K-page */
> +	fence->prl_sa = __xe_sa_bo_new(tile->mem.reclaim_pool,
> +				       XE_PAGE_RECLAIM_LIST_MAX_SIZE, GFP_ATOMIC);

Any reason we can't pass in the number of entries for better
suballocation? Or does PRL in GuC interface need to be page aligned?

> +	if (IS_ERR(fence->prl_sa))
> +		return -ENOMEM;
> +
> +	memcpy(xe_sa_bo_cpu_addr(fence->prl_sa), fence->reclaim_entries,
> +	       XE_PAGE_RECLAIM_LIST_MAX_SIZE);

If we had the number of entries we could save a few instructions on the
memory copy too.

> +	xe_sa_bo_flush_write(fence->prl_sa);
> +
> +	/* Queue up sa_bo_free on fence signal */
> +	xe_sa_bo_free(fence->prl_sa, &fence->base);
> +
> +	return 0;
> +}
>  
>  /**
>   * xe_page_reclaim_list_invalidate() - Mark a PRL as invalid
> diff --git a/drivers/gpu/drm/xe/xe_page_reclaim.h b/drivers/gpu/drm/xe/xe_page_reclaim.h
> index d066d7d97f79..f82b4d0865e0 100644
> --- a/drivers/gpu/drm/xe/xe_page_reclaim.h
> +++ b/drivers/gpu/drm/xe/xe_page_reclaim.h
> @@ -15,6 +15,9 @@
>  #define XE_PAGE_RECLAIM_MAX_ENTRIES	512
>  #define XE_PAGE_RECLAIM_LIST_MAX_SIZE	SZ_4K
>  
> +struct xe_tlb_inval;
> +struct xe_tlb_inval_fence;
> +
>  struct xe_guc_page_reclaim_entry {
>  	u32 valid:1;
>  	u32 reclamation_size:6;
> @@ -32,6 +35,7 @@ struct xe_page_reclaim_list {
>  #define XE_PAGE_RECLAIM_INVALID_LIST	-1
>  };
>  
> +int xe_page_reclaim_create_prl_bo(struct xe_tlb_inval *tlb_inval, struct xe_tlb_inval_fence *fence);
>  void xe_page_reclaim_list_invalidate(struct xe_page_reclaim_list *prl);
>  int xe_page_reclaim_list_alloc_entries(struct xe_page_reclaim_list *prl);
>  static inline void xe_page_reclaim_entries_get(struct xe_guc_page_reclaim_entry *entries)
> diff --git a/drivers/gpu/drm/xe/xe_tile.c b/drivers/gpu/drm/xe/xe_tile.c
> index 4f4f9a5c43af..63c060c2ea5c 100644
> --- a/drivers/gpu/drm/xe/xe_tile.c
> +++ b/drivers/gpu/drm/xe/xe_tile.c
> @@ -209,6 +209,11 @@ int xe_tile_init(struct xe_tile *tile)
>  	if (IS_ERR(tile->mem.kernel_bb_pool))
>  		return PTR_ERR(tile->mem.kernel_bb_pool);
>  
> +	/* Optimistically anticipate at most 256 TLB fences with PRL */
> +	tile->mem.reclaim_pool = xe_sa_bo_manager_init(tile, SZ_1M, XE_PAGE_RECLAIM_LIST_MAX_SIZE);
> +	if (IS_ERR(tile->mem.reclaim_pool))
> +		return PTR_ERR(tile->mem.reclaim_pool);
> +
>  	return 0;
>  }
>  void xe_tile_migrate_wait(struct xe_tile *tile)
> diff --git a/drivers/gpu/drm/xe/xe_tlb_inval.c b/drivers/gpu/drm/xe/xe_tlb_inval.c
> index de275759743c..67a047521165 100644
> --- a/drivers/gpu/drm/xe/xe_tlb_inval.c
> +++ b/drivers/gpu/drm/xe/xe_tlb_inval.c
> @@ -15,6 +15,7 @@
>  #include "xe_guc_ct.h"
>  #include "xe_guc_tlb_inval.h"
>  #include "xe_mmio.h"
> +#include "xe_page_reclaim.h"
>  #include "xe_pm.h"
>  #include "xe_tlb_inval.h"
>  #include "xe_trace.h"
> @@ -326,8 +327,19 @@ int xe_tlb_inval_range(struct xe_tlb_inval *tlb_inval,
>  		       struct xe_tlb_inval_fence *fence, u64 start, u64 end,
>  		       u32 asid, bool flush_cache)
>  {
> -	return xe_tlb_inval_issue(tlb_inval, fence, tlb_inval->ops->ppgtt,
> -				  start, end, asid, flush_cache);
> +	int err;
> +
> +	if (fence->reclaim_entries) {
> +		err = xe_page_reclaim_create_prl_bo(tlb_inval, fence);
> +		if (err) {
> +			flush_cache = true;
> +			fence->prl_sa = NULL;
> +		}
> +	}

Should we do the above step in run_job of the TLB invalidation job? I
think that might be cleaner wrt to layering and make it clear only TLB
invalidation jobs can use PRL. I don't see an easy way to implement
non-job based TLB invalidations with a PRL as those are typically in the
path of reclaim (no memory allocations).

> +	err = xe_tlb_inval_issue(tlb_inval, fence, tlb_inval->ops->ppgtt,
> +				 start, end, asid, flush_cache);
> +
> +	return err;
>  }
>  
>  /**
> @@ -461,4 +473,6 @@ void xe_tlb_inval_fence_init(struct xe_tlb_inval *tlb_inval,
>  		dma_fence_get(&fence->base);
>  	fence->tlb_inval = tlb_inval;
>  	fence->flush_cache = true;
> +	fence->reclaim_entries = NULL;
> +	fence->prl_sa = NULL;
>  }
> diff --git a/drivers/gpu/drm/xe/xe_tlb_inval_types.h b/drivers/gpu/drm/xe/xe_tlb_inval_types.h
> index c3c3943fb07e..7cf741e6a0c7 100644
> --- a/drivers/gpu/drm/xe/xe_tlb_inval_types.h
> +++ b/drivers/gpu/drm/xe/xe_tlb_inval_types.h
> @@ -9,6 +9,7 @@
>  #include <linux/workqueue.h>
>  #include <linux/dma-fence.h>
>  
> +struct xe_guc_page_reclaim_entry;
>  struct xe_tlb_inval;
>  
>  /** struct xe_tlb_inval_ops - TLB invalidation ops (backend) */
> @@ -129,6 +130,10 @@ struct xe_tlb_inval_fence {
>  	ktime_t inval_time;
>  	/** @flush_cache: bool for PPC flush, default is true */
>  	bool flush_cache;
> +	/** @reclaim_entries: list of pages to reclaim */
> +	struct xe_guc_page_reclaim_entry *reclaim_entries;
> +	/** @prl_sa: BO allocation for page reclaim list */
> +	struct drm_suballoc *prl_sa;

Again, let's try to hard move all of these things out the fence (store
them in the job if needed).

Matt

>  };
>  
>  #endif
> -- 
> 2.51.2
> 

  reply	other threads:[~2025-11-22 19:42 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18  9:05 [PATCH 00/11] Page Reclamation Support for Xe3p Platforms Brian Nguyen
2025-11-18  9:05 ` [PATCH 01/11] [DO, NOT, REVIEW] drm/xe: Do not forward invalid TLB invalidation seqnos to upper layers Brian Nguyen
2025-11-18  9:05 ` [PATCH 02/11] drm/xe: Reset tlb fence timeout on invalid seqno received Brian Nguyen
2025-11-21 17:23   ` Lin, Shuicheng
2025-11-22  1:53     ` Nguyen, Brian3
2025-11-22 18:25   ` Matthew Brost
2025-11-25 11:01     ` Nguyen, Brian3
2025-11-18  9:05 ` [PATCH 03/11] drm/xe/xe_tlb_inval: Modify fence interface to support PPC flush Brian Nguyen
2025-11-21 18:02   ` Lin, Shuicheng
2025-11-22  1:54     ` Nguyen, Brian3
2025-11-22 19:32   ` Matthew Brost
2025-11-25 11:07     ` Nguyen, Brian3
2025-11-18  9:05 ` [PATCH 04/11] drm/xe: Add page reclamation info to device info Brian Nguyen
2025-11-21 18:15   ` Lin, Shuicheng
2025-11-22 18:31   ` Matthew Brost
2025-11-18  9:05 ` [PATCH 05/11] drm/xe/guc: Add page reclamation interface to GuC Brian Nguyen
2025-11-21 18:32   ` Lin, Shuicheng
2025-11-22  1:56     ` Nguyen, Brian3
2025-11-22 18:39       ` Matthew Brost
2025-11-25 11:13         ` Nguyen, Brian3
2025-11-18  9:05 ` [PATCH 06/11] drm/xe: Create page reclaim list on unbind Brian Nguyen
2025-11-21 21:29   ` Lin, Shuicheng
2025-11-22  1:57     ` Nguyen, Brian3
2025-11-22 19:18   ` Matthew Brost
2025-11-25 11:18     ` Nguyen, Brian3
2025-11-25 18:34       ` Matthew Brost
2025-11-25 19:01         ` Nguyen, Brian3
2025-11-25 19:07           ` Matthew Brost
2025-11-25 19:46             ` Nguyen, Brian3
2025-11-25 22:35               ` Matthew Brost
2025-11-26  2:33                 ` Nguyen, Brian3
2025-11-18  9:05 ` [PATCH 07/11] drm/xe: Suballocate BO for page reclaim Brian Nguyen
2025-11-22 19:42   ` Matthew Brost [this message]
2025-11-25 11:20     ` Nguyen, Brian3
2025-11-18  9:05 ` [PATCH 08/11] drm/xe: Prep page reclaim in tlb inval job Brian Nguyen
2025-11-22 13:52   ` Michal Wajdeczko
2025-11-25 11:20     ` Nguyen, Brian3
2025-11-18  9:05 ` [PATCH 09/11] drm/xe: Append page reclamation action to tlb inval Brian Nguyen
2025-11-18  9:05 ` [PATCH 10/11] drm/xe: Optimize flushing of L2$ by skipping unnecessary page reclaim Brian Nguyen
2025-11-24 12:29   ` Matthew Auld
2025-11-25  6:12     ` Nguyen, Brian3
2025-11-25 11:48     ` Upadhyay, Tejas
2025-11-25 13:05       ` Upadhyay, Tejas
2025-11-18  9:05 ` [PATCH 11/11] drm/xe: Add debugfs support for page reclamation Brian Nguyen
2025-11-21 22:32   ` Lin, Shuicheng
2025-11-22  1:57     ` Nguyen, Brian3
2025-11-22 14:18   ` Michal Wajdeczko
2025-11-25 11:21     ` Nguyen, Brian3
2025-11-18  9:52 ` ✗ CI.checkpatch: warning for Page Reclamation Support for Xe3p Platforms Patchwork
2025-11-18  9:53 ` ✓ CI.KUnit: success " Patchwork
2025-11-18 13: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=aSISMU58l2MPAFcd@lstrano-desk.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=brian3.nguyen@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=shuicheng.lin@intel.com \
    --cc=stuart.summers@intel.com \
    --cc=tejas.upadhyay@intel.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