<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="ZH-CN" link="blue" vlink="purple" style="word-wrap:break-word"> [AMD Official Use Only - Internal Distribution Only] <div> <div class="WordSection1"> >> So gfx job hangs because it has a dependency on buggy compute job which already is hanging ?<o:p></o:p> No, there is no dependency between this gfx job and that compute job from a software perspective , but the CU is shared thus gfx is affected by the bug from that compute job <o:p></o:p> <o:p> </o:p> >> I am still missing something - we don't ever delete bad jobs or any jobs until they are signaled, we reinsert the bad job back into mirror list in drm_sched_stop<o:p></o:p> Oh yeah, it was still kept in the mirror list, I thought it was removed once for good in scheduler…<o:p></o:p> then my question is why we need to remove it in scheduler part if we always need to reinsert it back? And even for other vendors the better way is still<o:p></o:p> let vendor driver decide the heading job.<o:p></o:p> <o:p> </o:p> The real issue we hit is : sometimes if we run a quark test (it hangs kcq ring with a bad shader inside), X server will occasionally crash with a GFX ring TDR report<o:p></o:p> Root cause is still what I described before: both this innocent gfx job and the guilty compute job are all marked as “guilty” by our driver, so even they are re-inserted back to mirror list<o:p></o:p> But they are all abandoned in drm_sched_resubmit_jobs() due to they are all processed by drm_sched_increase_karma()<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> 发件人: Grodzovsky, Andrey <Andrey.Grodzovsky@amd.com> 发送时间: 2021年2月28日 8:55 收件人: Liu, Monk <Monk.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; amd-gfx@lists.freedesktop.org 抄送: Zhang, Andy <Andy.Zhang@amd.com>; Chen, Horace <Horace.Chen@amd.com>; Zhang, Jack (Jian) <Jack.Zhang1@amd.com> 主题: Re: 回复: [RFC] a new approach to detect which ring is the real black sheep upon TDR reported<o:p></o:p> </div> </div> <o:p> </o:p> <o:p> </o:p> <div> On 2021-02-26 10:56 p.m., Liu, Monk wrote:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [AMD Official Use Only - Internal Distribution Only]<o:p></o:p> <o:p> </o:p> <div> H Andrey<o:p></o:p> <o:p></o:p> The scenario I hit here is not the one you mentioned, let me explain it with more details by another much easier understood example:<o:p></o:p> <o:p></o:p> Consider ring you have a job1 on KCQ, but the timeout of KCQ is 60 seconds (just for example)<o:p></o:p> You also have a job2 on GFX ring, and the timeout of GFX is 2 seconds<o:p></o:p> <o:p></o:p> We submit job1 first, and assume job1 have bug and it will cause shader hang very very soon <o:p></o:p> After 10 seconds we submit job2, since KCQ have 60 seconds to report TDR thus SW know nothing about the engine already hang<o:p></o:p> </div> </blockquote> <o:p> </o:p> So gfx job hangs because it has a dependency on buggy compute job which already is hanging ?<o:p></o:p> <o:p> </o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> After 2 seconds we got TDR report from job2 on GFX ring, sched_job_timeout() think the leading job of GFX ring is the black sheep so it is deleted from the mirror list<o:p></o:p> But in fact this job1 is innocent, and we should insert it back after recovery , and due to it was already deleted this innocent job’s context/process is really harmed<o:p></o:p> </div> </blockquote> <o:p> </o:p> I am still missing something - we don't ever delete bad jobs or any jobs until they are signaled, we reinsert the bad job back into mirror list in drm_sched_stop (here - <a href="https://elixir.bootlin.com/linux/v5.11.1/source/drivers/gpu/drm/scheduler/sched_main.c#L385"> https://elixir.bootlin.com/linux/v5.11.1/source/drivers/gpu/drm/scheduler/sched_main.c#L385</a>) after sched thread is stopped and continue with the reset procedure.<o:p></o:p> Andrey<o:p></o:p> <o:p> </o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <o:p></o:p> Hope above example helps<o:p></o:p> <o:p></o:p> Thanks <o:p></o:p> <o:p></o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> 发件人: Grodzovsky, Andrey <a href="mailto:Andrey.Grodzovsky@amd.com"><Andrey.Grodzovsky@amd.com></a> 发送时间: 2021年2月27日 0:50 收件人: Liu, Monk <a href="mailto:Monk.Liu@amd.com"> <Monk.Liu@amd.com></a>; Koenig, Christian <a href="mailto:Christian.Koenig@amd.com"> <Christian.Koenig@amd.com></a>; <a href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> 抄送: Zhang, Andy <a href="mailto:Andy.Zhang@amd.com"> <Andy.Zhang@amd.com></a>; Chen, Horace <a href="mailto:Horace.Chen@amd.com"><Horace.Chen@amd.com></a>; Zhang, Jack (Jian) <a href="mailto:Jack.Zhang1@amd.com"><Jack.Zhang1@amd.com></a> 主题: Re: [RFC] a new approach to detect which ring is the real black sheep upon TDR reported<o:p></o:p> </div> </div> <o:p></o:p> <o:p></o:p> <div> On 2021-02-26 6:54 a.m., Liu, Monk wrote:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [AMD Official Use Only - Internal Distribution Only]<o:p></o:p> <o:p></o:p> See in line<o:p></o:p> <o:p></o:p> <div> Thanks <o:p></o:p> <o:p></o:p> ------------------------------------------<o:p></o:p> Monk Liu | Cloud-GPU Core team<o:p></o:p> ------------------------------------------<o:p></o:p> </div> <o:p></o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: Koenig, Christian <a href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a> Sent: Friday, February 26, 2021 3:58 PM To: Liu, Monk <a href="mailto:Monk.Liu@amd.com"><Monk.Liu@amd.com></a>; <a href="mailto:amd-gfx@lists.freedesktop.org"> amd-gfx@lists.freedesktop.org</a> Cc: Zhang, Andy <a href="mailto:Andy.Zhang@amd.com"><Andy.Zhang@amd.com></a>; Chen, Horace <a href="mailto:Horace.Chen@amd.com"><Horace.Chen@amd.com></a>; Zhang, Jack (Jian) <a href="mailto:Jack.Zhang1@amd.com"><Jack.Zhang1@amd.com></a> Subject: Re: [RFC] a new approach to detect which ring is the real black sheep upon TDR reported<o:p></o:p> </div> </div> <o:p></o:p> Hi Monk, in general an interesting idea, but I see two major problems with that: 1. It would make the reset take much longer. 2. Things get often stuck because of timing issues, so a guilty job might pass perfectly when run a second time.<o:p></o:p> [ML] but the innocent ring already reported a TDR, and the drm sched logic already deleted this “sched_job” in its mirror list, thus you don’t have chance to re-submit it again after reset, that’s the major problem here.<o:p></o:p> </blockquote> <o:p></o:p> Just to confirm I understand correctly, Monk reports a scenario where the second TDR that was reported by the innocent job is bailing out BEFORE having a chance to run drm_sched_stop for that scheduler which should have reinserted the job back into mirror list (because the first TDR run is still in progress and hence amdgpu_device_lock_adev fails for the second TDR) and so the innocent job which was extracted from mirror list in drm_sched_job_timedout is now lost. If so and as a possible quick fix until we overhaul the entire design as suggested in this thread - maybe we can modify drm_sched_backend_ops.timedout_job callback to report back premature termination BEFORE drm_sched_stop had a chance to run and then reinsert back the job into mirror list from within drm_sched_job_timedout? There is no problem of racing against concurrent drm_sched_get_cleanup_job once we reinsert there as we don't reference the job pointer anymore after this point and so if it's already signaled and freed right away - it's ok. <o:p></o:p> Andrey<o:p></o:p> <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> Apart from that the whole ring mirror list turned out to be a really bad idea. E.g. we still struggle with object life time because the concept doesn't fit into the object model of the GPU scheduler under Linux. We should probably work on this separately and straighten up the job destruction once more and keep the recovery information in the fence instead.<o:p></o:p> [ML] we claim to our customer that no innocent process will be dropped or cancelled, and our current logic works for the most time, but only when there are different process running on gfx/computes rings then we would run into the tricky situation I stated here, and the proposal is the only way I can figure out so far, do you have a better solution or idea we review it as another candidate RFC ? Be note that we raised this proposal is because we do hit our trouble and we do need to resolve it …. So even a not perfect solution is still better than just cancel the innocent job (and their context/process)<o:p></o:p> Thanks ! <o:p> </o:p> Regards, Christian.<o:p></o:p> <div> Am 26.02.21 um 06:58 schrieb Liu, Monk:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [AMD Public Use]<o:p></o:p> <o:p></o:p> Hi all<o:p></o:p> <o:p></o:p> NAVI2X project hit a really hard to solve issue now, and it is turned out to be a general headache of our TDR mechanism , check below scenario:<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">There is a job1 running on compute1 ring at timestamp <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">There is a job2 running on gfx ring at timestamp<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">Job1 is the guilty one, and job1/job2 were scheduled to their rings at almost the same timestamp <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">After 2 seconds we receive two TDR reporting from both GFX ring and compute ring<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">Current scheme is that in drm scheduler all the head jobs of those two rings are considered “bad job” and taken away from the mirror list <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">The result is both the real guilty job (job1) and the innocent job (job2) were all deleted from mirror list, and their corresponding contexts were also treated as guilty (so the innocent process remains running is not secured)<o:p></o:p></li></ol> <o:p></o:p> But by our wish the ideal case is TDR mechanism can detect which ring is the guilty ring and the innocent ring can resubmits all its pending jobs:<o:p></o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo2">Job1 to be deleted from compute1 ring’s mirror list<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo2">Job2 is kept and resubmitted later and its belonging process/context are even not aware of this TDR at all <o:p></o:p></li></ol> <o:p></o:p> <o:p></o:p> Here I have a proposal tend to achieve above goal and it rough procedure is :<o:p></o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo3">Once any ring reports a TDR, the head job is *not* treated as “bad job”, and it is *not* deleted from the mirror list in drm sched functions<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo3">In vendor’s function (our amdgpu driver here):<o:p></o:p></li></ol> <ol style="margin-top:0cm" start="2" type="1"> <ul style="margin-top:0cm" type="disc"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level2 lfo3">reset GPU<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level2 lfo3">repeat below actions on each RINGS * one by one *:<o:p></o:p></li></ul> </ol> <![if !supportLists]>1. <![endif]>take the head job and submit it on this ring<o:p></o:p> <![if !supportLists]>2. <![endif]>see if it completes, if not then this job is the real “bad job”<o:p></o:p> <![if !supportLists]>3. <![endif]> take it away from mirror list if this head job is “bad job”<o:p></o:p> <ol style="margin-top:0cm" start="2" type="1"> <ul style="margin-top:0cm" type="disc"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level2 lfo3">After above iteration on all RINGS, we already clears all the bad job(s)<o:p></o:p></li></ul> </ol> <ol style="margin-top:0cm" start="3" type="1"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo3">Resubmit all jobs from each mirror list to their corresponding rings (this is the existed logic)<o:p></o:p></li></ol> <o:p></o:p> The idea of this is to use “serial” way to re-run and re-check each head job of each RING, in order to take out the real black sheep and its guilty context.<o:p></o:p> <o:p></o:p> P.S.: we can use this approaches only on GFX/KCQ ring reports TDR , since those rings are intermutually affected to each other. For SDMA ring timeout it definitely proves the head job on SDMA ring is really guilty.<o:p></o:p> <o:p></o:p> Thanks <o:p></o:p> <o:p></o:p> ------------------------------------------<o:p></o:p> Monk Liu | Cloud-GPU Core team<o:p></o:p> ------------------------------------------<o:p></o:p> <o:p></o:p> </blockquote> <o:p></o:p> <o:p></o:p> <pre>_______________________________________________<o:p></o:p></pre> <pre>amd-gfx mailing list<o:p></o:p></pre> <pre><a href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a><o:p></o:p></pre> <pre><a href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a><o:p></o:p></pre> </blockquote> </div> </blockquote> </div> </div> </body> </html>