From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
To: "Grodzovsky,
Andrey" <Andrey.Grodzovsky-5C7GfCeVMHo@public.gmane.org>,
Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Kazlauskas,
Nicholas" <Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH v3 1/5] drm/scheduler: rework job destruction
Date: Tue, 16 Apr 2019 14:43:01 +0000 [thread overview]
Message-ID: <4d7c99ae-eec4-f6af-6865-7c844475078c@amd.com> (raw)
In-Reply-To: <84200035-bb50-310d-7d48-20dbe072621c-5C7GfCeVMHo@public.gmane.org>
Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
> On 4/16/19 5:47 AM, Christian König wrote:
>> Am 15.04.19 um 23:17 schrieb Eric Anholt:
>>> Andrey Grodzovsky <andrey.grodzovsky@amd.com> writes:
>>>
>>>> From: Christian König <christian.koenig@amd.com>
>>>>
>>>> We now destroy finished jobs from the worker thread to make sure that
>>>> we never destroy a job currently in timeout processing.
>>>> By this we avoid holding lock around ring mirror list in drm_sched_stop
>>>> which should solve a deadlock reported by a user.
>>>>
>>>> v2: Remove unused variable.
>>>>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692
>>>>
>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>> ---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++--
>>>> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 -
>>>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 +-
>>>> drivers/gpu/drm/scheduler/sched_main.c | 138
>>>> +++++++++++++++++------------
>>>> drivers/gpu/drm/v3d/v3d_sched.c | 9 +-
>>> Missing corresponding panfrost and lima updates. You should probably
>>> pull in drm-misc for hacking on the scheduler.
>>>
>>>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
>>>> b/drivers/gpu/drm/v3d/v3d_sched.c
>>>> index ce7c737b..8efb091 100644
>>>> --- a/drivers/gpu/drm/v3d/v3d_sched.c
>>>> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
>>>> @@ -232,11 +232,18 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d,
>>>> struct drm_sched_job *sched_job)
>>>> /* block scheduler */
>>>> for (q = 0; q < V3D_MAX_QUEUES; q++)
>>>> - drm_sched_stop(&v3d->queue[q].sched);
>>>> + drm_sched_stop(&v3d->queue[q].sched, sched_job);
>>>> if(sched_job)
>>>> drm_sched_increase_karma(sched_job);
>>>> + /*
>>>> + * Guilty job did complete and hence needs to be manually removed
>>>> + * See drm_sched_stop doc.
>>>> + */
>>>> + if (list_empty(&sched_job->node))
>>>> + sched_job->sched->ops->free_job(sched_job);
>>> If the if (sched_job) is necessary up above, then this should clearly be
>>> under it.
>>>
>>> But, can we please have a core scheduler thing we call here instead of
>>> drivers all replicating it?
>> Yeah that's also something I noted before.
>>
>> Essential problem is that we remove finished jobs from the mirror list
>> and so need to destruct them because we otherwise leak them.
>>
>> Alternative approach here would be to keep the jobs on the ring mirror
>> list, but not submit them again.
>>
>> Regards,
>> Christian.
>
> I really prefer to avoid this, it means adding extra flag to sched_job
> to check in each iteration of the ring mirror list.
Mhm, why actually? We just need to check if the scheduler fence is signaled.
> What about changing
> signature of drm_sched_backend_ops.timedout_job to return drm_sched_job*
> instead of void, this way we can return the guilty job back from the
> driver specific handler to the generic drm_sched_job_timedout and
> release it there.
Well the timeout handler already has the job, so returning it doesn't
make much sense.
The problem is rather that the timeout handler doesn't know if it should
destroy the job or not.
Christian.
>
> Andrey
>
>>>> +
>>>> /* get the GPU back into the init state */
>>>> v3d_reset(v3d);
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-04-16 14:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-15 19:43 [PATCH v3 1/5] drm/scheduler: rework job destruction Andrey Grodzovsky
[not found] ` <1555357403-30813-1-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2019-04-15 19:43 ` [PATCH v3 2/5] drm/sched: Keep s_fence->parent pointer Andrey Grodzovsky
2019-04-15 19:43 ` [PATCH v3 3/5] drm/amdgpu: Avoid HW reset if guilty job already signaled Andrey Grodzovsky
2019-04-15 19:43 ` [PATCH v3 4/5] drm/amd/display: wait for fence without holding reservation lock Andrey Grodzovsky
2019-04-15 19:43 ` [PATCH v3 5/5] Patch '5edb0c9b Fix deadlock with display during hanged ring recovery' was accidentaly removed during one of DALs code merges Andrey Grodzovsky
[not found] ` <1555357403-30813-5-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2019-04-15 20:00 ` Kazlauskas, Nicholas
2019-04-15 21:17 ` [PATCH v3 1/5] drm/scheduler: rework job destruction Eric Anholt
[not found] ` <878swb6k9a.fsf-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
2019-04-16 9:47 ` Christian König
[not found] ` <b62ea5d8-1dbe-7e67-7e62-1f452ed860c2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-04-16 14:36 ` Grodzovsky, Andrey
[not found] ` <84200035-bb50-310d-7d48-20dbe072621c-5C7GfCeVMHo@public.gmane.org>
2019-04-16 14:43 ` Koenig, Christian [this message]
[not found] ` <4d7c99ae-eec4-f6af-6865-7c844475078c-5C7GfCeVMHo@public.gmane.org>
2019-04-16 14:58 ` Grodzovsky, Andrey
[not found] ` <e8255594-6a3f-ba83-e6ff-d6aae4e9e9ba-5C7GfCeVMHo@public.gmane.org>
2019-04-16 15:42 ` Grodzovsky, Andrey
[not found] ` <93c03b16-b01f-d17e-49d3-4cce515052aa-5C7GfCeVMHo@public.gmane.org>
2019-04-16 16:00 ` Koenig, Christian
[not found] ` <8344ae6b-03a8-0a9b-aa02-66b59b580f37-5C7GfCeVMHo@public.gmane.org>
2019-04-17 21:06 ` Grodzovsky, Andrey
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=4d7c99ae-eec4-f6af-6865-7c844475078c@amd.com \
--to=christian.koenig-5c7gfcevmho@public.gmane.org \
--cc=Andrey.Grodzovsky-5C7GfCeVMHo@public.gmane.org \
--cc=Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org \
--cc=etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
/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