All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	<thomas.hellstrom@linux.intel.com>, <stuart.summers@intel.com>,
	<arvind.yadav@intel.com>, <tejas.upadhyay@intel.com>
Subject: Re: [RFC 05/15] drm/xe: Implement xe_access_counter_handler
Date: Thu, 2 Apr 2026 19:06:11 -0700	[thread overview]
Message-ID: <ac8gk1MaTl64ttbS@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260318074456.2839499-6-himal.prasad.ghimiray@intel.com>

On Wed, Mar 18, 2026 at 01:14:46PM +0530, Himal Prasad Ghimiray wrote:
> Enqueue access counter notifications to the appropriate queue based on
> ASID and schedule worker to process them.
> 
> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_access_counter.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_access_counter.c b/drivers/gpu/drm/xe/xe_access_counter.c
> index cafcc42897f8..a2ce9dc45d05 100644
> --- a/drivers/gpu/drm/xe/xe_access_counter.c
> +++ b/drivers/gpu/drm/xe/xe_access_counter.c
> @@ -87,12 +87,29 @@ int xe_access_counter_init(struct xe_device *xe)
>   * @xe: xe device
>   * @ac: access counter notification
>   *
> - * Process an access counter notification from the producer layer.
> + * Sink the access counter notification to a queue (i.e., a memory buffer) and
> + * queue a worker to service it.
>   *
>   * Return: 0 on success, negative error code on error
>   */
>  int xe_access_counter_handler(struct xe_device *xe, struct xe_access_counter *ac)
>  {
> -	/* Stub implementation - to be filled in */
> -	return 0;
> +	struct xe_usm_queue *ac_queue = xe->usm.ac_queue +
> +		(ac->consumer.xe3.asid % XE_ACCESS_COUNTER_QUEUE_COUNT);

So again, let’s go with a single-queue [1], multiple-worker design.
Also, do not pick a worker based on ASID hashing, because once we move
to fine-grained locking [2], we can service access counters using
vm->lock in read mode.

Yes, BO-based migrations still need the VM dma-resv lock, so we would
serialize there, but given how BO migrations and binds are pipelined,
this ends up being a relatively small window unless we wait on the
migration under VM's dma-resv lock, which we don't need to do. SVM or
userptr (assuming we implement this eventually) access-counter migration
would remain pretty much fully parallel on the same VM.

Matt

[1] https://patchwork.freedesktop.org/patch/712591/?series=163429&rev=1#comment_1317960
[2] https://patchwork.freedesktop.org/patch/707294/?series=162167&rev=4

> +	unsigned long flags;
> +	bool full;
> +
> +	spin_lock_irqsave(&ac_queue->lock, flags);
> +	full = xe_usm_queue_full(ac_queue, sizeof(struct xe_access_counter));
> +	if (!full) {
> +		xe_usm_queue_push(ac_queue, ac, xe_access_counter_entry_size());
> +		queue_work(xe->usm.pf_wq, &ac_queue->worker);
> +	} else {
> +		drm_warn(&xe->drm,
> +			 "AccessCounter Queue (%d) full, shouldn't be possible\n",
> +			 ac->consumer.xe3.asid % XE_ACCESS_COUNTER_QUEUE_COUNT);
> +	}
> +	spin_unlock_irqrestore(&ac_queue->lock, flags);
> +
> +	return full ? -ENOSPC : 0;
>  }
> -- 
> 2.34.1
> 

  reply	other threads:[~2026-04-03  2:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18  7:44 [RFC 00/15] drm/xe: Access counter consumer layer Himal Prasad Ghimiray
2026-03-18  7:34 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-18  7:35 ` ✗ CI.KUnit: failure " Patchwork
2026-03-18  7:44 ` [RFC 01/15] drm/xe: Add xe_usm_queue generic USM circular buffer Himal Prasad Ghimiray
2026-04-01 21:28   ` Matthew Brost
2026-04-06  4:46     ` Ghimiray, Himal Prasad
2026-03-18  7:44 ` [RFC 02/15] drm/xe/pagefault: Use xe_usm_queue helpers Himal Prasad Ghimiray
2026-03-18  7:44 ` [RFC 03/15] drm/xe: Stub out new access_counter layer Himal Prasad Ghimiray
2026-04-02 21:46   ` Matthew Brost
2026-04-06  5:28     ` Ghimiray, Himal Prasad
2026-04-14 20:06   ` Summers, Stuart
2026-03-18  7:44 ` [RFC 04/15] drm/xe: Implement xe_access_counter_init Himal Prasad Ghimiray
2026-03-18  7:44 ` [RFC 05/15] drm/xe: Implement xe_access_counter_handler Himal Prasad Ghimiray
2026-04-03  2:06   ` Matthew Brost [this message]
2026-03-18  7:44 ` [RFC 06/15] drm/xe: Extract xe_vma_lock_and_validate helper Himal Prasad Ghimiray
2026-04-01 22:03   ` Matthew Brost
2026-03-18  7:44 ` [RFC 07/15] drm/xe: Move ASID to FAULT VM lookup to xe_device Himal Prasad Ghimiray
2026-04-02 21:50   ` Matthew Brost
2026-04-07  6:41     ` Ghimiray, Himal Prasad
2026-03-18  7:44 ` [RFC 08/15] drm/xe: Implement xe_access_counter_queue_work Himal Prasad Ghimiray
2026-04-01 21:10   ` Matthew Brost
2026-04-01 22:01     ` Matthew Brost
2026-04-01 22:11   ` Matthew Brost
2026-04-02 22:06   ` Matthew Brost
2026-04-22 20:35   ` Summers, Stuart
2026-03-18  7:44 ` [RFC 09/15] drm/xe/trace: Add xe_vma_acc trace event for access counter notifications Himal Prasad Ghimiray
2026-04-03  1:01   ` Matthew Brost
2026-03-18  7:44 ` [RFC 10/15] drm/xe/svm: Handle svm ranges on access ctr trigger Himal Prasad Ghimiray
2026-04-03  0:25   ` Matthew Brost
2026-03-18  7:44 ` [RFC 11/15] drm/xe: Add xe_guc_access_counter layer Himal Prasad Ghimiray
2026-04-02 21:27   ` Matthew Brost
2026-04-14 21:24   ` Summers, Stuart
2026-04-22 20:38   ` Summers, Stuart
2026-03-18  7:44 ` [RFC 12/15] drm/xe/uapi: Add access counter parameter extension for exec queue Himal Prasad Ghimiray
2026-03-24 14:25   ` Francois Dugast
2026-04-01 14:46     ` Matthew Brost
2026-04-01 16:36       ` Ghimiray, Himal Prasad
2026-03-18  7:44 ` [RFC 13/15] drm/xe/lrc: Pass exec_queue to xe_lrc_create for access counter params Himal Prasad Ghimiray
2026-04-22 20:50   ` Summers, Stuart
2026-03-18  7:44 ` [RFC 14/15] drm/xe/vm: Add xe_vma_supports_access_ctr() helper Himal Prasad Ghimiray
2026-04-22 20:54   ` Summers, Stuart
2026-03-18  7:44 ` [RFC 15/15] drm/xe/pt: Set NC PTE bit for VMAs ineligible for access counting Himal Prasad Ghimiray
2026-04-03  0:09   ` Matthew Brost

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=ac8gk1MaTl64ttbS@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=arvind.yadav@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=stuart.summers@intel.com \
    --cc=tejas.upadhyay@intel.com \
    --cc=thomas.hellstrom@linux.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 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.