From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Nirmoy Das <nirmoy.das@intel.com>, <intel-xe@lists.freedesktop.org>
Cc: Matthew Brost <matthew.brost@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
John Harrison <John.C.Harrison@Intel.com>,
"Himal Prasad Ghimiray" <himal.prasad.ghimiray@intel.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
"Anshuman Gupta" <Anshuman.Gupta@intel.com>
Subject: Re: [PATCH] drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout
Date: Thu, 24 Oct 2024 15:32:19 +0530 [thread overview]
Message-ID: <20af74cb-1ade-4f75-b73c-7e75b3651a00@intel.com> (raw)
In-Reply-To: <20241023151343.3463640-1-nirmoy.das@intel.com>
On 23-10-2024 20:43, Nirmoy Das wrote:
> Flush the g2h worker explicitly if TLB timeout happens which is
> observed on LNL and that points recent scheduling issue with E-cores.
> This is similar to the recent fix:
> commit e51527233804 ("drm/xe/guc/ct: Flush g2h worker in case of g2h
> response timeout") and should be removed once there is E core
> scheduling fix.
>
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2687
> Cc: Badal Nilawar <badal.nilawar@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: John Harrison <John.C.Harrison@Intel.com>
> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
> drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
> index 773de1f08db9..2c327dccbd74 100644
> --- a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
> +++ b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
> @@ -72,6 +72,15 @@ static void xe_gt_tlb_fence_timeout(struct work_struct *work)
> struct xe_device *xe = gt_to_xe(gt);
> struct xe_gt_tlb_invalidation_fence *fence, *next;
>
> + /*
> + * This is analogous to e51527233804 ("drm/xe/guc/ct: Flush g2h worker
> + * in case of g2h response timeout")
> + *
> + * TODO: Drop this change once workqueue scheduling delay issue is
> + * fixed on LNL Hybrid CPU.
> + */
> + flush_work(>->uc.guc.ct.g2h_worker);
I didn't get the idea of flushing g2h worker here. Moreover AFAIK tlb
invalidation is handled in fast path xe_guc_ct_fast_path i.e. in IRQ
handler itself. Is this change solving the issue.
static inline void xe_guc_ct_irq_handler(struct xe_guc_ct *ct)
{
if (!xe_guc_ct_enabled(ct))
return;
wake_up_all(&ct->wq);
queue_work(ct->g2h_wq, &ct->g2h_worker);
xe_guc_ct_fast_path(ct);
}
Regards,
Badal
> +
> spin_lock_irq(>->tlb_invalidation.pending_lock);
> list_for_each_entry_safe(fence, next,
> >->tlb_invalidation.pending_fences, link) {
next prev parent reply other threads:[~2024-10-24 10:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 15:13 [PATCH] drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout Nirmoy Das
2024-10-23 22:42 ` Matthew Brost
2024-10-24 2:02 ` Ghimiray, Himal Prasad
2024-10-24 9:15 ` Nirmoy Das
2024-10-24 8:17 ` ✓ CI.Patch_applied: success for " Patchwork
2024-10-24 8:17 ` ✓ CI.checkpatch: " Patchwork
2024-10-24 8:18 ` ✓ CI.KUnit: " Patchwork
2024-10-24 8:30 ` ✓ CI.Build: " Patchwork
2024-10-24 8:32 ` ✓ CI.Hooks: " Patchwork
2024-10-24 8:34 ` ✓ CI.checksparse: " Patchwork
2024-10-24 8:59 ` ✗ CI.BAT: failure " Patchwork
2024-10-24 10:02 ` Nilawar, Badal [this message]
2024-10-24 10:17 ` [PATCH] " Nirmoy Das
2024-10-24 13:00 ` Nilawar, Badal
2024-10-24 13:11 ` Matthew Auld
2024-10-24 13:22 ` Nirmoy Das
2024-10-24 13:54 ` Nilawar, Badal
2024-10-24 13:12 ` Nirmoy Das
2024-10-24 13:56 ` Nilawar, Badal
2024-10-24 17:00 ` ✓ CI.FULL: success 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=20af74cb-1ade-4f75-b73c-7e75b3651a00@intel.com \
--to=badal.nilawar@intel.com \
--cc=Anshuman.Gupta@intel.com \
--cc=John.C.Harrison@Intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=nirmoy.das@intel.com \
--cc=rodrigo.vivi@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.