AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Joshua Ashton" <joshua@froggi.es>,
	"Friedrich Vock" <friedrich.vock@gmx.de>,
	"Felix Kuehling" <felix.kuehling@amd.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Dommati, Sunil-kumar" <Sunil-kumar.Dommati@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/amdgpu: Reset IH OVERFLOW_CLEAR bit after writing rptr
Date: Tue, 23 Jan 2024 10:36:39 +0100	[thread overview]
Message-ID: <2906c98e-47fe-4a39-b32d-9d060d571076@amd.com> (raw)
In-Reply-To: <dc8506c4-9114-473e-bfdc-8a24f2264392@froggi.es>



Am 22.01.24 um 23:39 schrieb Joshua Ashton:
> [SNIP]
>>>
>>> Most work submissions in practice submit more waves than the number of
>>> wave slots the GPU has.
>>> As far as I understand soft recovery, the only thing it does is kill 
>>> all
>>> active waves. This frees up the CUs so more waves are launched, which
>>> can fault again, and that leads to potentially lots of faults for a
>>> single wave slot in the end.
>>
>> Exactly that, but killing each wave takes a moment since we do that 
>> in a loop with a bit delay in there.
>>
>> So the interrupt handler should at least in theory have time to catch 
>> up.
>
> I don't think there is any delay in that loop is there?

Mhm, looks like I remember that incorrectly.

>
>     while (!dma_fence_is_signaled(fence) &&
>            ktime_to_ns(ktime_sub(deadline, ktime_get())) > 0)
>         ring->funcs->soft_recovery(ring, vmid);
>
> (soft_recovery function does not have a delay/sleep/whatever either)
>
> FWIW, two other changes we did in SteamOS to make recovery more 
> reliable on VANGOGH was:
>
> 1) Move the timeout determination after the spinlock setting the fence 
> error.

Well that should not really have any effect.

>
> 2) Raise the timeout from 0.1s to 1s.

Well that's not necessarily a good idea. If the SQ isn't able to respond 
in 100ms then I would really go into a hard reset.

Waiting one extra second is way to long here.

Regards,
Christian.

>
> - Joshie 🐸✨
>
>
>>
>> Regards,
>> Christian.
>>
>>>
>>> Regards,
>>> Friedrich
>


  reply	other threads:[~2024-01-23  9:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-14 13:00 [PATCH 1/2] drm/amdgpu: Reset IH OVERFLOW_CLEAR bit after writing rptr Friedrich Vock
2024-01-14 13:00 ` [PATCH 2/2] drm/amdgpu: Process fences on IH overflow Friedrich Vock
2024-01-15 10:26   ` Christian König
2024-01-15 11:19     ` Friedrich Vock
2024-01-16  7:17       ` Christian König
     [not found] ` <69cec077-4011-4738-bbb0-8fb1e6f52159@gmail.com>
2024-01-15 11:18   ` [PATCH 1/2] drm/amdgpu: Reset IH OVERFLOW_CLEAR bit after writing rptr Friedrich Vock
2024-01-16  7:03     ` Christian König
2024-01-16 10:31       ` Friedrich Vock
2024-01-17 12:27         ` Christian König
2024-01-17 23:00           ` Alex Deucher
2024-01-17 23:44             ` Friedrich Vock
2024-01-18 12:07               ` Christian König
2024-01-19 19:18                 ` Felix Kuehling
2024-01-22 10:10                   ` Christian König
2024-01-22 10:21                     ` Friedrich Vock
2024-01-22 10:45                       ` Friedrich Vock
2024-01-22 13:35                         ` Christian König
2024-01-22 22:39                           ` Joshua Ashton
2024-01-23  9:36                             ` Christian König [this message]
2024-01-23 11:35                               ` Friedrich Vock
2024-01-23 12:49                                 ` Christian König
2024-02-02 11:11                                   ` Joshua Ashton
2024-02-02 13:31                                     ` Christian König

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=2906c98e-47fe-4a39-b32d-9d060d571076@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Sunil-kumar.Dommati@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=felix.kuehling@amd.com \
    --cc=friedrich.vock@gmx.de \
    --cc=joshua@froggi.es \
    /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