From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
John Harrison <john.c.harrison@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <anshuman.gupta@intel.com>,
<rodrigo.vivi@intel.com>, <matthew.auld@intel.com>
Subject: Re: [PATCH 2/3] drm/xe/guc/ct: Increase wait timeout for g2h response
Date: Mon, 14 Oct 2024 17:42:29 +0530 [thread overview]
Message-ID: <38aad4cb-e4e1-45e2-a8a1-e0f24fac51a3@intel.com> (raw)
In-Reply-To: <Zwhd56R8t69f9hLi@DUT025-TGLU.fm.intel.com>
Hi Matt, John,
Thanks for review comments.
On 11-10-2024 04:36, Matthew Brost wrote:
> On Wed, Oct 09, 2024 at 12:43:36PM -0700, John Harrison wrote:
>> On 10/9/2024 03:56, Badal Nilawar wrote:
>>> Occasionally, the G2H worker starts running after a delay of more than
>>> a second even after being queued and activated by the Linux workqueue
>>> subsystem.
>>> To prevent G2H timeout errors, the wait timeout is being increased.
>>>
>>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1620
>>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2902
>>> Signed-off-by: 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>
>>> ---
>>> drivers/gpu/drm/xe/xe_guc_ct.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
>>> index b93b2821e4e8..dcc95c01b6f0 100644
>>> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
>>> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
>>> @@ -1019,7 +1019,7 @@ static int guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
>>> return ret;
>>> }
>>> - ret = wait_event_timeout(ct->g2h_fence_wq, g2h_fence.done, HZ);
>>> + ret = wait_event_timeout(ct->g2h_fence_wq, g2h_fence.done, HZ * 3);
>> Is this change intended to be temporary until the fundamental scheduling
>> issue with the workqueue is fixed? If so, there should be a TODO comment to
>> that effect so that we remember to shrink the timeout back down again later.
>> Three seconds seems like a long time to wait.
>>
>
> I fine with this W/A until we root cause the work queue scheduling issue
> but agree this needs a comment explaining why this large timeout is
> needed (work queue scheduling issue), how to trigger the larger timeout
> (tests which can trigger this), and saying once we root cause issue
> reduce the timeout.
Sure, I will add the comment here and in patch 3 to explain why this is
needed and change need to be reverted once this is fixed.
Regards,
Badal
>
> Matt
>
>> John.
>>
>>> /*
>>> * It is possible that the g2h request may be cancelled while waiting for a response due
>>
next prev parent reply other threads:[~2024-10-14 12:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 10:56 [PATCH 0/3] Handle G2H response timeout Badal Nilawar
2024-10-09 10:56 ` [PATCH 1/3] drm/xe/guc/ct: Improve g2h request handling during async gt reset Badal Nilawar
2024-10-09 19:41 ` John Harrison
2024-10-10 23:03 ` Matthew Brost
2024-10-10 23:01 ` Matthew Brost
2024-10-14 12:10 ` Nilawar, Badal
2024-10-14 15:57 ` Matthew Brost
2024-10-09 10:56 ` [PATCH 2/3] drm/xe/guc/ct: Increase wait timeout for g2h response Badal Nilawar
2024-10-09 19:43 ` John Harrison
2024-10-10 23:06 ` Matthew Brost
2024-10-14 12:12 ` Nilawar, Badal [this message]
2024-10-17 9:54 ` Anshuman Gupta
2024-10-09 10:56 ` [PATCH 3/3] drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout Badal Nilawar
2024-10-09 19:50 ` John Harrison
2024-10-10 23:09 ` Matthew Brost
2024-10-09 13:58 ` ✓ CI.Patch_applied: success for Handle G2H " Patchwork
2024-10-09 13:58 ` ✓ CI.checkpatch: " Patchwork
2024-10-09 14:00 ` ✓ CI.KUnit: " Patchwork
2024-10-09 14:13 ` ✓ CI.Build: " Patchwork
2024-10-09 14:15 ` ✓ CI.Hooks: " Patchwork
2024-10-09 14:17 ` ✓ CI.checksparse: " Patchwork
2024-10-09 14:45 ` ✓ CI.BAT: " Patchwork
2024-10-09 22:54 ` ✗ CI.FULL: failure " 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=38aad4cb-e4e1-45e2-a8a1-e0f24fac51a3@intel.com \
--to=badal.nilawar@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox