From: Matthew Brost <matthew.brost@intel.com>
To: Nirmoy Das <nirmoy.das@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH v4] drm/xe/ufence: Signal ufence faster when possible
Date: Sat, 9 Nov 2024 19:51:00 -0800 [thread overview]
Message-ID: <ZzAtpNKoOGusN0VW@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20241018152958.1975994-1-nirmoy.das@intel.com>
On Fri, Oct 18, 2024 at 05:29:58PM +0200, Nirmoy Das wrote:
> When the backing fence is already signaled, the ufence can be
> immediately signaled without queuing in the ordered work queue.
> This should also reduce load from the xe ordered_wq and won't
> block signaling a ufence which doesn't require any serialization.
>
> v2: fix system_wq typo
> v3: signal immediately instead of queuing in system_wq (Matt B)
> v4: revert back to v2 of using workqueue because of locking issue
> and remote viewing a different mm struct.
> Use Xe's unordered_wq which should be less congested than global
> one.
>
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1630
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
> drivers/gpu/drm/xe/xe_sync.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_sync.c b/drivers/gpu/drm/xe/xe_sync.c
> index a90480c6aecf..7a1558c7ce09 100644
> --- a/drivers/gpu/drm/xe/xe_sync.c
> +++ b/drivers/gpu/drm/xe/xe_sync.c
> @@ -92,18 +92,27 @@ static void user_fence_worker(struct work_struct *w)
> user_fence_put(ufence);
> }
>
> -static void kick_ufence(struct xe_user_fence *ufence, struct dma_fence *fence)
> +static void kick_ufence_ordered(struct xe_user_fence *ufence,
> + struct dma_fence *fence)
> {
> INIT_WORK(&ufence->worker, user_fence_worker);
> queue_work(ufence->xe->ordered_wq, &ufence->worker);
> dma_fence_put(fence);
> }
>
> +static void kick_ufence_unordered(struct xe_user_fence *ufence,
> + struct dma_fence *fence)
> +{
> + INIT_WORK(&ufence->worker, user_fence_worker);
> + queue_work(ufence->xe->unordered_wq, &ufence->worker);
This doesn't work, if this has been merged it needs to be reverted.
Consider the case when a user requests two user fence writes to same
address in the fashion of a seqno (i.e. 2nd write is one more the value
of the first). If we use an unordered work queue, the 2nd write could
pass the first resulting in the seqno being incorrect.
Matt
> + dma_fence_put(fence);
> +}
> +
> static void user_fence_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
> {
> struct xe_user_fence *ufence = container_of(cb, struct xe_user_fence, cb);
>
> - kick_ufence(ufence, fence);
> + kick_ufence_ordered(ufence, fence);
> }
>
> int xe_sync_entry_parse(struct xe_device *xe, struct xe_file *xef,
> @@ -239,7 +248,16 @@ void xe_sync_entry_signal(struct xe_sync_entry *sync, struct dma_fence *fence)
> err = dma_fence_add_callback(fence, &sync->ufence->cb,
> user_fence_cb);
> if (err == -ENOENT) {
> - kick_ufence(sync->ufence, fence);
> + /*
> + * use unordered_wq to schedule it faster and to keep
> + * the ordered_wq less loaded as serialization is not
> + * needed for when the fence is already signaled.
> + *
> + * This needs to be done with a wq here to avoid locking
> + * issue when a ufence addr is backed by a bo and also
> + * tsk->mm needs to null to call kthread_use_mm().
> + */
> + kick_ufence_unordered(sync->ufence, fence);
> } else if (err) {
> XE_WARN_ON("failed to add user fence");
> user_fence_put(sync->ufence);
> --
> 2.46.0
>
next prev parent reply other threads:[~2024-11-10 3:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 15:29 [PATCH v4] drm/xe/ufence: Signal ufence faster when possible Nirmoy Das
2024-10-18 16:16 ` ✓ CI.Patch_applied: success for " Patchwork
2024-10-18 16:17 ` ✓ CI.checkpatch: " Patchwork
2024-10-18 16:18 ` ✓ CI.KUnit: " Patchwork
2024-10-18 16:29 ` ✓ CI.Build: " Patchwork
2024-10-18 16:32 ` ✓ CI.Hooks: " Patchwork
2024-10-18 16:35 ` ✓ CI.checksparse: " Patchwork
2024-10-18 16:58 ` ✓ CI.BAT: " Patchwork
2024-10-19 6:56 ` ✗ CI.FULL: failure " Patchwork
2024-10-22 16:06 ` [PATCH v4] " Cavitt, Jonathan
2024-11-07 11:23 ` ✓ CI.Patch_applied: success for drm/xe/ufence: Signal ufence faster when possible (rev2) Patchwork
2024-11-07 11:23 ` ✓ CI.checkpatch: " Patchwork
2024-11-07 11:24 ` ✓ CI.KUnit: " Patchwork
2024-11-07 11:36 ` ✓ CI.Build: " Patchwork
2024-11-07 11:38 ` ✓ CI.Hooks: " Patchwork
2024-11-07 11:39 ` ✓ CI.checksparse: " Patchwork
2024-11-07 12:04 ` ✓ CI.BAT: " Patchwork
2024-11-08 18:12 ` ✗ CI.FULL: failure " Patchwork
2024-11-10 3:51 ` Matthew Brost [this message]
2024-11-11 14:49 ` [PATCH v4] drm/xe/ufence: Signal ufence faster when possible Nirmoy Das
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=ZzAtpNKoOGusN0VW@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=nirmoy.das@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