[SNIP]
Maybe just empirically - let's try it and see under different
test scenarios what actually happens ?
Not a good idea in general, we have that approach way to often at
AMD and are then surprised that everything works in QA but fails
in production.
But Daniel already noted in
On 2021-04-15 3:02 a.m., Christian König wrote:
Am 15.04.21 um 08:27 schrieb Andrey Grodzovsky:
On 2021-04-14 10:58 a.m., Christian König wrote:
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we
Am 15.04.21 um 08:27 schrieb Andrey Grodzovsky:
On 2021-04-14 10:58 a.m., Christian König wrote:
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we first stop the all schedulers, then
only call
On 2021-04-14 10:58 a.m., Christian König wrote:
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we first stop the all schedulers, then
only call drm_sched_entity_kill_jobs.
The schedulers
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we first stop the all schedulers, then
only call drm_sched_entity_kill_jobs.
The schedulers consuming jobs is not the problem, we already handle
that
On 2021-04-14 3:01 a.m., Christian König wrote:
Am 13.04.21 um 20:30 schrieb Andrey Grodzovsky:
On 2021-04-13 2:25 p.m., Christian König wrote:
Am 13.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-13 2:03 p.m., Christian König wrote:
Am 13.04.21 um 17:12 schrieb Andrey Grodzovsky:
Am 13.04.21 um 20:30 schrieb Andrey Grodzovsky:
On 2021-04-13 2:25 p.m., Christian König wrote:
Am 13.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-13 2:03 p.m., Christian König wrote:
Am 13.04.21 um 17:12 schrieb Andrey Grodzovsky:
On 2021-04-13 3:10 a.m., Christian König wrote:
gt; ; Li, Dennis ;
> amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Kuehling, Felix ; Zhang,
> Hawking ; Daniel Vetter
> Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance its stability
>
> Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
> >
> > On
On Tue, Apr 13, 2021 at 9:10 AM Christian König
wrote:
>
> Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
> >
> > On 2021-04-12 3:18 p.m., Christian König wrote:
> >> Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
> >>> [SNIP]
> >
> > So what's the right approach ? How we guarantee that
On 2021-04-13 2:25 p.m., Christian König wrote:
Am 13.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-13 2:03 p.m., Christian König wrote:
Am 13.04.21 um 17:12 schrieb Andrey Grodzovsky:
On 2021-04-13 3:10 a.m., Christian König wrote:
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
Am 13.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-13 2:03 p.m., Christian König wrote:
Am 13.04.21 um 17:12 schrieb Andrey Grodzovsky:
On 2021-04-13 3:10 a.m., Christian König wrote:
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
On 2021-04-12 3:18 p.m., Christian König wrote:
On 2021-04-13 2:03 p.m., Christian König wrote:
Am 13.04.21 um 17:12 schrieb Andrey Grodzovsky:
On 2021-04-13 3:10 a.m., Christian König wrote:
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
On 2021-04-12 3:18 p.m., Christian König wrote:
Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
Am 13.04.21 um 17:12 schrieb Andrey Grodzovsky:
On 2021-04-13 3:10 a.m., Christian König wrote:
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
On 2021-04-12 3:18 p.m., Christian König wrote:
Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
[SNIP]
So what's the right approach ? How we
On 2021-04-13 3:10 a.m., Christian König wrote:
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
On 2021-04-12 3:18 p.m., Christian König wrote:
Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
[SNIP]
So what's the right approach ? How we guarantee that when running
Christian ; Li, Dennis
; amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Kuehling,
Felix ; Zhang, Hawking ; Daniel Vetter
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance its stability
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
On 2021-04-12 3:18 p.m., Christian König
tian König
Sent: Tuesday, April 13, 2021 3:10 PM
To: Grodzovsky, Andrey ; Koenig, Christian
; Li, Dennis ;
amd-gfx@lists.freedesktop.org; Deucher, Alexander ;
Kuehling, Felix ; Zhang, Hawking
; Daniel Vetter
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance its stability
Am 12.04.2
Am 12.04.21 um 22:01 schrieb Andrey Grodzovsky:
On 2021-04-12 3:18 p.m., Christian König wrote:
Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
[SNIP]
So what's the right approach ? How we guarantee that when running
amdgpu_fence_driver_force_completion we will signal all the HW
fences
Am 13.04.21 um 07:36 schrieb Andrey Grodzovsky:
[SNIP]
emit_fence(fence);
*/* We can't wait forever as the HW might be gone at any point*/**
dma_fence_wait_timeout(old_fence, 5S);*
You can pretty much ignore this wait here. It is only as a last
resort so that we never overwrite
On 2021-04-12 2:23 p.m., Christian König wrote:
Am 12.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-12 2:05 p.m., Christian König wrote:
Am 12.04.21 um 20:01 schrieb Andrey Grodzovsky:
On 2021-04-12 1:44 p.m., Christian König wrote:
Am 12.04.21 um 19:27 schrieb Andrey
On 2021-04-12 3:18 p.m., Christian König wrote:
Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
[SNIP]
So what's the right approach ? How we guarantee that when running
amdgpu_fence_driver_force_completion we will signal all the HW
fences and not racing against some more fences insertion
Am 12.04.21 um 21:12 schrieb Andrey Grodzovsky:
[SNIP]
So what's the right approach ? How we guarantee that when running
amdgpu_fence_driver_force_completion we will signal all the HW
fences and not racing against some more fences insertion into that
array ?
Well I would still say the
On 2021-04-12 2:23 p.m., Christian König wrote:
Am 12.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-12 2:05 p.m., Christian König wrote:
Am 12.04.21 um 20:01 schrieb Andrey Grodzovsky:
On 2021-04-12 1:44 p.m., Christian König wrote:
Am 12.04.21 um 19:27 schrieb Andrey
Am 12.04.21 um 20:18 schrieb Andrey Grodzovsky:
On 2021-04-12 2:05 p.m., Christian König wrote:
Am 12.04.21 um 20:01 schrieb Andrey Grodzovsky:
On 2021-04-12 1:44 p.m., Christian König wrote:
Am 12.04.21 um 19:27 schrieb Andrey Grodzovsky:
On 2021-04-10 1:34 p.m., Christian König wrote:
On 2021-04-12 2:05 p.m., Christian König wrote:
Am 12.04.21 um 20:01 schrieb Andrey Grodzovsky:
On 2021-04-12 1:44 p.m., Christian König wrote:
Am 12.04.21 um 19:27 schrieb Andrey Grodzovsky:
On 2021-04-10 1:34 p.m., Christian König wrote:
Hi Andrey,
Am 09.04.21 um 20:18 schrieb Andrey
Am 12.04.21 um 20:01 schrieb Andrey Grodzovsky:
On 2021-04-12 1:44 p.m., Christian König wrote:
Am 12.04.21 um 19:27 schrieb Andrey Grodzovsky:
On 2021-04-10 1:34 p.m., Christian König wrote:
Hi Andrey,
Am 09.04.21 um 20:18 schrieb Andrey Grodzovsky:
[SNIP]
If we use a list and a flag
On 2021-04-12 1:44 p.m., Christian König wrote:
Am 12.04.21 um 19:27 schrieb Andrey Grodzovsky:
On 2021-04-10 1:34 p.m., Christian König wrote:
Hi Andrey,
Am 09.04.21 um 20:18 schrieb Andrey Grodzovsky:
[SNIP]
If we use a list and a flag called 'emit_allowed' under a lock
such that in
Am 12.04.21 um 19:27 schrieb Andrey Grodzovsky:
On 2021-04-10 1:34 p.m., Christian König wrote:
Hi Andrey,
Am 09.04.21 um 20:18 schrieb Andrey Grodzovsky:
[SNIP]
If we use a list and a flag called 'emit_allowed' under a lock
such that in amdgpu_fence_emit we lock the list, check the flag
On 2021-04-10 1:34 p.m., Christian König wrote:
Hi Andrey,
Am 09.04.21 um 20:18 schrieb Andrey Grodzovsky:
[SNIP]
If we use a list and a flag called 'emit_allowed' under a lock such
that in amdgpu_fence_emit we lock the list, check the flag and if
true add the new HW fence to list and
Hi Andrey,
Am 09.04.21 um 20:18 schrieb Andrey Grodzovsky:
[SNIP]
If we use a list and a flag called 'emit_allowed' under a lock such
that in amdgpu_fence_emit we lock the list, check the flag and if
true add the new HW fence to list and proceed to HW emition as
normal, otherwise return
On 2021-04-09 12:39 p.m., Christian König wrote:
Am 09.04.21 um 17:42 schrieb Andrey Grodzovsky:
On 2021-04-09 3:01 a.m., Christian König wrote:
Am 09.04.21 um 08:53 schrieb Christian König:
Am 08.04.21 um 22:39 schrieb Andrey Grodzovsky:
[SNIP]
But inserting dmr_dev_enter/exit on the
Am 09.04.21 um 17:42 schrieb Andrey Grodzovsky:
On 2021-04-09 3:01 a.m., Christian König wrote:
Am 09.04.21 um 08:53 schrieb Christian König:
Am 08.04.21 um 22:39 schrieb Andrey Grodzovsky:
[SNIP]
But inserting dmr_dev_enter/exit on the highest level in drm_ioctl
is much less effort and
On 2021-04-09 3:01 a.m., Christian König wrote:
Am 09.04.21 um 08:53 schrieb Christian König:
Am 08.04.21 um 22:39 schrieb Andrey Grodzovsky:
On 2021-04-08 2:58 p.m., Christian König wrote:
Am 08.04.21 um 18:08 schrieb Andrey Grodzovsky:
On 2021-04-08 4:32 a.m., Christian König wrote:
Am
Am 09.04.21 um 08:53 schrieb Christian König:
Am 08.04.21 um 22:39 schrieb Andrey Grodzovsky:
On 2021-04-08 2:58 p.m., Christian König wrote:
Am 08.04.21 um 18:08 schrieb Andrey Grodzovsky:
On 2021-04-08 4:32 a.m., Christian König wrote:
Am 08.04.21 um 10:22 schrieb Christian König:
[SNIP]
Am 08.04.21 um 22:39 schrieb Andrey Grodzovsky:
On 2021-04-08 2:58 p.m., Christian König wrote:
Am 08.04.21 um 18:08 schrieb Andrey Grodzovsky:
On 2021-04-08 4:32 a.m., Christian König wrote:
Am 08.04.21 um 10:22 schrieb Christian König:
[SNIP]
Beyond blocking all delayed works and
On 2021-04-08 2:58 p.m., Christian König wrote:
Am 08.04.21 um 18:08 schrieb Andrey Grodzovsky:
On 2021-04-08 4:32 a.m., Christian König wrote:
Am 08.04.21 um 10:22 schrieb Christian König:
[SNIP]
Beyond blocking all delayed works and scheduler threads we also
need to guarantee no IOCTL
Am 08.04.21 um 18:08 schrieb Andrey Grodzovsky:
On 2021-04-08 4:32 a.m., Christian König wrote:
Am 08.04.21 um 10:22 schrieb Christian König:
[SNIP]
Beyond blocking all delayed works and scheduler threads we also
need to guarantee no IOCTL can access MMIO post device unplug OR
in flight
felix.kuehl...@amd.com>>;
Zhang, Hawking <mailto:hawking.zh...@amd.com>>
*Betreff:* RE: [PATCH 0/4] Refine GPU recovery sequence to
enhance its stability
>>> Those two steps need to be exchanged or otherwise it is
possible that new delayed work items etc are started be
t;>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
*Betreff:* RE: [PATCH 0/4] Refine GPU recovery sequence to
enhance its stability
>>> Those two steps need to be exchanged or otherwise it is
possible that n
ailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
*Betreff:* RE: [PATCH 0/4] Refine GPU recovery sequence to
enhance its stability
>>> Those two steps need to be exchanged or otherwise it is
possible that new delayed work items etc are started bef
org>; Deucher, Alexander
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance
its stability
Am 18.03.21 um 08:23 schrieb Dennis Li
Deucher, Alexander
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance
its stability
Am 18.03.21 um 08:23 schrieb Dennis Li:
>
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance
its stability
Am 18.03.21 um 08:23 schrieb Dennis Li:
> We have defined two var
>; amd-gfx@lists.freedesktop.org
<mailto:amd-gfx@lists.freedesktop.org>
<mailto:amd-gfx@lists.freedesktop.org>>; Deucher, Alexander
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com&g
Alexander
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
*Betreff:* RE: [PATCH 0/4] Refine GPU recovery sequence to enhance
its stability
>>> Those two steps need to be ex
Alexander
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
*Betreff:* RE: [PATCH 0/4] Refine GPU recovery sequence to enhance
its stability
>>> Those two steps need to be exchanged o
op.org> <mailto:amd-gfx@lists.freedesktop.org>>; Deucher, Alexander
mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix <mailto:felix.kuehl...@amd.com>>; Zhang, Hawking
mailto:hawking.zh...@amd.com>>
*Betreff:* RE: [PATCH 0/4] Refine GPU recovery sequence to
s.freedesktop.org>; Deucher,
Alexander mailto:alexander.deuc...@amd.com>>;
Kuehling, Felix mailto:felix.kuehl...@amd.com>>; Zhang,
Hawking mailto:hawking.zh...@amd.com>>
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance its stability
Am 18.03.21 um 08:23 schri
:54 PM
To: Li, Dennis ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Kuehling, Felix
; Zhang, Hawking
Subject: Re: [PATCH 0/4] Refine GPU recovery sequence to enhance its stability
Am 18.03.21 um 08:23 schrieb Dennis Li:
> We have defined two variables in_gpu_reset and reset_sem in ad
Am 18.03.21 um 08:23 schrieb Dennis Li:
We have defined two variables in_gpu_reset and reset_sem in adev object. The
atomic type variable in_gpu_reset is used to avoid recovery thread reenter and
make lower functions return more earlier when recovery start, but couldn't
block recovery thread
49 matches
Mail list logo
