Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>,
	intel-xe@lists.freedesktop.org,
	Jonathan Cavitt <jonathan.cavitt@intel.com>
Subject: Re: [PATCH] drm/xe/oa: Disallow OA from being enabled on active exec_queue's
Date: Fri, 22 Nov 2024 09:49:16 -0800	[thread overview]
Message-ID: <85serjjh0j.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <85ttc0j8lv.wl-ashutosh.dixit@intel.com>

On Thu, 21 Nov 2024 18:38:36 -0800, Dixit, Ashutosh wrote:
>
> Doing what I outlined above (submitting to the user exec queue), or doing
> what you are suggesting (submitting directly to the ring), is not an
> insignificant amount of work. E.g. submitting a MI_LRI command to the ring
> requires allocating the batch buffer in the user/exec_queue VM. And even
> then writing directly to the ring would race with the scheduler potentially
> submitting simultaneously to the same ring (see guc_exec_queue_run_job).

Incidentally, for the above reason, submitting directly to the ring would
need introduction of a new lock in the submission path and therefore will
likely not fly. In Xe, as opposed to i915, everything is submitted to the
scheduler and it is only the scheduler which submits to the ring.

Therefore, if we ever do this, my guess we'd have to submit to the user
exec queue instead, as I was saying. I am not sure if there will still be
locking issues in the kernel allocating its batches from the userspace VM,
but they are likely to be less serious than introducing a new lock in the
submission path.

Ashutosh

  reply	other threads:[~2024-11-22 17:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19  1:32 [PATCH] drm/xe/oa: Disallow OA from being enabled on active exec_queue's Ashutosh Dixit
2024-11-19  2:10 ` ✓ CI.Patch_applied: success for " Patchwork
2024-11-19  2:10 ` ✓ CI.checkpatch: " Patchwork
2024-11-19  2:11 ` ✓ CI.KUnit: " Patchwork
2024-11-19  2:29 ` ✓ CI.Build: " Patchwork
2024-11-19  2:32 ` ✓ CI.Hooks: " Patchwork
2024-11-19  2:33 ` ✓ CI.checksparse: " Patchwork
2024-11-19  3:00 ` ✓ CI.BAT: " Patchwork
2024-11-19 14:44 ` [PATCH] " Matthew Brost
2024-11-19 21:08   ` Dixit, Ashutosh
2024-11-19 22:09     ` Matthew Brost
2024-11-21  4:22       ` Dixit, Ashutosh
2024-11-21  5:16         ` Matthew Brost
2024-11-21 21:04           ` Dixit, Ashutosh
2024-11-21 22:06     ` Umesh Nerlige Ramappa
2024-11-22  2:38       ` Dixit, Ashutosh
2024-11-22 17:49         ` Dixit, Ashutosh [this message]
2024-11-19 15:19 ` Cavitt, Jonathan
2024-11-19 15:46 ` ✗ CI.FULL: failure for " 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=85serjjh0j.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jonathan.cavitt@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=umesh.nerlige.ramappa@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