From: Matthew Brost <matthew.brost@intel.com>
To: "Nguyen, Brian3" <brian3.nguyen@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Upadhyay, Tejas" <tejas.upadhyay@intel.com>,
"Lin, Shuicheng" <shuicheng.lin@intel.com>,
"Summers, Stuart" <stuart.summers@intel.com>,
"Wajdeczko, Michal" <Michal.Wajdeczko@intel.com>
Subject: Re: [PATCH v2 08/11] drm/xe: Prep page reclaim in tlb inval job
Date: Thu, 4 Dec 2025 10:05:21 -0800 [thread overview]
Message-ID: <aTHNYbsoSJV/hNdx@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <SA1PR11MB8839764A5C743C00807BE25AAAA6A@SA1PR11MB8839.namprd11.prod.outlook.com>
On Wed, Dec 03, 2025 at 10:42:00PM -0700, Nguyen, Brian3 wrote:
> On Wednesday, December 3, 2025 5:21 PM, Matthew Brost wrote:
> > On Wed, Dec 03, 2025 at 05:22:10PM -0700, Nguyen, Brian3 wrote:
> > > On Wednesday, December 3, 2025 3:14 PM, Matthew Brost wrote:
> > > > On Thu, Nov 27, 2025 at 07:02:09AM +0800, Brian Nguyen wrote:
> > > > > Use page reclaim list as indicator if page reclaim action is
> > > > > desired and pass it to tlb inval fence to handle.
> > > > >
> > > > > Job will need to maintain its own embedded copy to ensure lifetime
> > > > > of PRL exist until job has run.
> > > > >
> > > > > v2:
> > > > > - Use xe variant of WARN_ON (Michal)
> > > > >
> > > > > Signed-off-by: Brian Nguyen <brian3.nguyen@intel.com>
> > > > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > > > > ---
> > > > > drivers/gpu/drm/xe/xe_pt.c | 6 ++++++
> > > > > drivers/gpu/drm/xe/xe_tlb_inval_job.c | 26
> > > > > ++++++++++++++++++++++++++ drivers/gpu/drm/xe/xe_tlb_inval_job.h |
> > > > > 4 ++++
> > > > > 3 files changed, 36 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/xe/xe_pt.c
> > > > > b/drivers/gpu/drm/xe/xe_pt.c index 347b111dc097..833d6762dd8d
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_pt.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_pt.c
> > > > > @@ -2498,6 +2498,12 @@ xe_pt_update_ops_run(struct xe_tile *tile, struct xe_vma_ops *vops)
> > > > > goto kill_vm_tile1;
> > > > > }
> > > > > update.ijob = ijob;
> > > > > + if (pt_update_ops->prl.num_entries != XE_PAGE_RECLAIM_INVALID_LIST) {
> > > > > + xe_tlb_inval_job_add_page_reclaim(ijob, &pt_update_ops->prl);
> > > > > + /* Release ref from alloc, job will now handle it */
> > > > > + xe_page_reclaim_entries_put(pt_update_ops->prl.entries);
> > > > > + pt_update_ops->prl.entries = NULL;
> > > > > + }
> > > >
> > > > Do we not need to do this on the media-GT? Or is issuing PRL a single GuC sufficient?
> > > >
> > > > Everything else looks good.
> > > >
> > >
> > > It should be sufficient per tile. KMD will request GuC FW per tile and
> > > afterwards GuC FW will issue Page Reclamation to all the primary XeTLBs, for GT and media within the tile.
> > >
> > > However, I realize that this means we should be disabling PPC flush
> > > for media TLB invalidation otherwise, it will conflict and do a PPC
> > > flush anyway. Will have to rework some of the logic to handle this if so... Taking another look at this.
> >
> > Yes, that's a good catch and would've missed this part. Now I'm wondering if on upstream devices if flushing the PPC cache on both
> > primary GT and media GT is really neeeded. If not, this might be small perf win.
> >
>
> I asked Nekkalapu, Satyanarayana for HW perspective confirmation. Media doesn't have any PPC to speak of,
> so, it looks like PPC flush bit for media translate to a NOP so we wouldn't be getting any perf here on upstream,
> maybe skipping a handshake at most.
>
> So, regardless of PPC bit enabled or disabled for media, it shouldn't interfere with the primary GT caches.
>
> Therefore, I will plan to keep this logic the same for simplicity unless you suggest otherwise.
>
Can you just add a comment around why we only add the PRL to the primary
GT? To naive reader of the code it immediately looks like a bug that PRL
is only attached to the primary GT.
Matt
> Brian
>
> > Matt
> >
> > >
> > > Brian
> > >
> > > > Matt
> > > >
> > > > >
> > > > > if (tile->media_gt) {
> > > > > dep_scheduler = to_dep_scheduler(q, tile->media_gt); diff
> > > > > --git a/drivers/gpu/drm/xe/xe_tlb_inval_job.c
> > > > > b/drivers/gpu/drm/xe/xe_tlb_inval_job.c
> > > > > index dbd3171fff12..2185f42b9644 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_tlb_inval_job.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_tlb_inval_job.c
> > > > > @@ -7,7 +7,9 @@
> > > > > #include "xe_dep_job_types.h"
> > > > > #include "xe_dep_scheduler.h"
> > > > > #include "xe_exec_queue.h"
> > > > > +#include "xe_gt_printk.h"
> > > > > #include "xe_gt_types.h"
> > > > > +#include "xe_page_reclaim.h"
> > > > > #include "xe_tlb_inval.h"
> > > > > #include "xe_tlb_inval_job.h"
> > > > > #include "xe_migrate.h"
> > > > > @@ -116,6 +118,7 @@ xe_tlb_inval_job_create(struct xe_exec_queue *q, struct xe_tlb_inval *tlb_inval,
> > > > > job->start = start;
> > > > > job->end = end;
> > > > > job->fence_armed = false;
> > > > > + xe_page_reclaim_list_init(&job->prl);
> > > > > job->dep.ops = &dep_job_ops;
> > > > > job->type = type;
> > > > > kref_init(&job->refcount);
> > > > > @@ -149,6 +152,25 @@ xe_tlb_inval_job_create(struct xe_exec_queue *q, struct xe_tlb_inval *tlb_inval,
> > > > > return ERR_PTR(err);
> > > > > }
> > > > >
> > > > > +/**
> > > > > + * xe_tlb_inval_job_add_page_reclaim() - Embed PRL into a TLB job
> > > > > + * @job: TLB invalidation job that may trigger reclamation
> > > > > + * @prl: Page reclaim list populated during unbind
> > > > > + *
> > > > > + * Copies @prl into the job and takes an extra reference to the
> > > > > +entry page so
> > > > > + * ownership can transfer to the TLB fence when the job is pushed.
> > > > > + */
> > > > > +void xe_tlb_inval_job_add_page_reclaim(struct xe_tlb_inval_job *job,
> > > > > + struct xe_page_reclaim_list *prl) {
> > > > > + struct xe_device *xe = gt_to_xe(job->q->gt);
> > > > > +
> > > > > + xe_gt_WARN_ON(job->q->gt, !xe->info.has_page_reclaim_hw_assist);
> > > > > + job->prl = *prl;
> > > > > + /* Pair with put after bo creation */
> > > > > + xe_page_reclaim_entries_get(job->prl.entries);
> > > > > +}
> > > > > +
> > > > > static void xe_tlb_inval_job_destroy(struct kref *ref) {
> > > > > struct xe_tlb_inval_job *job = container_of(ref, typeof(*job),
> > > > > @@
> > > > > -159,6 +181,10 @@ static void xe_tlb_inval_job_destroy(struct kref *ref)
> > > > > struct xe_device *xe = gt_to_xe(q->gt);
> > > > > struct xe_vm *vm = job->vm;
> > > > >
> > > > > + /* BO creation retains a copy (if used), so no longer needed */
> > > > > + if (job->prl.entries)
> > > > > + xe_page_reclaim_entries_put(job->prl.entries);
> > > > > +
> > > > > if (!job->fence_armed)
> > > > > kfree(ifence);
> > > > > else
> > > > > diff --git a/drivers/gpu/drm/xe/xe_tlb_inval_job.h
> > > > > b/drivers/gpu/drm/xe/xe_tlb_inval_job.h
> > > > > index 4d6df1a6c6ca..03d6e21cd611 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_tlb_inval_job.h
> > > > > +++ b/drivers/gpu/drm/xe/xe_tlb_inval_job.h
> > > > > @@ -12,6 +12,7 @@ struct dma_fence; struct xe_dep_scheduler;
> > > > > struct xe_exec_queue; struct xe_migrate;
> > > > > +struct xe_page_reclaim_list;
> > > > > struct xe_tlb_inval;
> > > > > struct xe_tlb_inval_job;
> > > > > struct xe_vm;
> > > > > @@ -21,6 +22,9 @@ xe_tlb_inval_job_create(struct xe_exec_queue *q, struct xe_tlb_inval *tlb_inval,
> > > > > struct xe_dep_scheduler *dep_scheduler,
> > > > > struct xe_vm *vm, u64 start, u64 end, int type);
> > > > >
> > > > > +void xe_tlb_inval_job_add_page_reclaim(struct xe_tlb_inval_job *job,
> > > > > + struct xe_page_reclaim_list *prl);
> > > > > +
> > > > > int xe_tlb_inval_job_alloc_dep(struct xe_tlb_inval_job *job);
> > > > >
> > > > > struct dma_fence *xe_tlb_inval_job_push(struct xe_tlb_inval_job
> > > > > *job,
> > > > > --
> > > > > 2.52.0
> > > > >
next prev parent reply other threads:[~2025-12-04 18:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 23:02 [PATCH v2 00/11] Page Reclamation Support for Xe3p Platforms Brian Nguyen
2025-11-26 23:02 ` [PATCH v2 01/11] [DO, NOT, REVIEW] drm/xe: Do not forward invalid TLB invalidation seqnos to upper layers Brian Nguyen
2025-11-26 23:02 ` [PATCH v2 02/11] drm/xe: Reset tlb fence timeout on invalid seqno received Brian Nguyen
2025-12-02 22:24 ` Matthew Brost
2025-11-26 23:02 ` [PATCH v2 03/11] drm/xe/xe_tlb_inval: Modify fence interface to support PPC flush Brian Nguyen
2025-12-02 22:18 ` Matthew Brost
2025-11-26 23:02 ` [PATCH v2 04/11] drm/xe: Add page reclamation info to device info Brian Nguyen
2025-11-26 23:02 ` [PATCH v2 05/11] drm/xe/guc: Add page reclamation interface to GuC Brian Nguyen
2025-12-02 22:21 ` Matthew Brost
2025-12-03 0:17 ` Lin, Shuicheng
2025-11-26 23:02 ` [PATCH v2 06/11] drm/xe: Create page reclaim list on unbind Brian Nguyen
2025-12-01 21:45 ` Nguyen, Brian3
2025-12-03 22:56 ` Matthew Brost
2025-12-04 0:19 ` Nguyen, Brian3
2025-11-26 23:02 ` [PATCH v2 07/11] drm/xe: Suballocate BO for page reclaim Brian Nguyen
2025-12-03 23:06 ` Matthew Brost
2025-11-26 23:02 ` [PATCH v2 08/11] drm/xe: Prep page reclaim in tlb inval job Brian Nguyen
2025-12-03 23:13 ` Matthew Brost
2025-12-04 0:22 ` Nguyen, Brian3
2025-12-04 1:20 ` Matthew Brost
2025-12-04 5:42 ` Nguyen, Brian3
2025-12-04 18:05 ` Matthew Brost [this message]
2025-12-04 20:02 ` Nguyen, Brian3
2025-12-09 5:57 ` Upadhyay, Tejas
2025-12-09 6:14 ` Nguyen, Brian3
2025-11-26 23:02 ` [PATCH v2 09/11] drm/xe: Append page reclamation action to tlb inval Brian Nguyen
2025-12-03 23:15 ` Matthew Brost
2025-11-26 23:02 ` [PATCH v2 10/11] drm/xe: Optimize flushing of L2$ by skipping unnecessary page reclaim Brian Nguyen
2025-12-09 14:23 ` Upadhyay, Tejas
2025-11-26 23:02 ` [PATCH v2 11/11] drm/xe: Add debugfs support for page reclamation Brian Nguyen
2025-12-02 22:28 ` Matthew Brost
2025-12-02 22:51 ` Nguyen, Brian3
2025-12-02 22:59 ` Matthew Brost
2025-12-05 18:02 ` Lin, Shuicheng
2025-11-26 23:52 ` ✗ CI.checkpatch: warning for Page Reclamation Support for Xe3p Platforms (rev2) Patchwork
2025-11-26 23:54 ` ✓ CI.KUnit: success " Patchwork
2025-11-27 0:54 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-11-27 1:42 ` ✗ Xe.CI.Full: " 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=aTHNYbsoSJV/hNdx@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=Michal.Wajdeczko@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