From: Steven Price <steven.price@arm.com>
To: "Christian König" <christian.koenig@amd.com>,
"Arvind Yadav" <Arvind.Yadav@amd.com>,
andrey.grodzovsky@amd.com, shashank.sharma@amd.com,
amaranath.somalapuram@amd.com, Arunpravin.PaneerSelvam@amd.com,
sumit.semwal@linaro.org, gustavo@padovan.org, airlied@linux.ie,
daniel@ffwll.ch, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 5/6] drm/sched: Use parent fence instead of finished
Date: Thu, 29 Sep 2022 16:31:44 +0100 [thread overview]
Message-ID: <ccb55f39-2d7d-1e9d-91ac-70f609370e22@arm.com> (raw)
In-Reply-To: <5beff5e2-8589-28cf-40b4-9e6b9e45b307@amd.com>
On 29/09/2022 15:57, Christian König wrote:
> Am 29.09.22 um 16:53 schrieb Steven Price:
>> On 14/09/2022 17:43, Arvind Yadav wrote:
>>> Using the parent fence instead of the finished fence
>>> to get the job status. This change is to avoid GPU
>>> scheduler timeout error which can cause GPU reset.
>> I'm able to reproduce crashes on Panfrost and I believe this commit is
>> the cause. Specifically it's possible for job->s_fence->parent to be
>> NULL.
>>
>> The underlying issue seems to involve drm_sched_resubmit_jobs_ext() - if
>> the run_jobs() callback returns an error it will set s_fence->parent to
>> NULL after signalling s_fence->finished:
>>
>>> fence = sched->ops->run_job(s_job);
>>> i++;
>>>
>>> if (IS_ERR_OR_NULL(fence)) {
>>> if (IS_ERR(fence))
>>> dma_fence_set_error(&s_fence->finished, PTR_ERR(fence));
>>>
>>> s_job->s_fence->parent = NULL;
>> I don't understand the reasoning behind this change, but it doesn't seem
>> right to be using the parent fence when we have code which can be
>> setting that pointer to NULL.
>>
>> Since I don't understand the reasoning my only suggestion is to revert
>> this patch (and potentially the dependent patch "dma-buf: Check status
>> of enable-signaling bit on debug"?).
>>
>> Can anyone suggest a better fix?
>
> Well, first of all please absolutely don't use
> drm_sched_resubmit_jobs_ext()!
Panfrost isn't using drm_sched_resubmit_jobs_ext() directly but via
drm_sched_resubmit_jobs().
> It was an extremely bad idea in amdgpu to approach GPU by re-submitting
> jobs and it was an even worse idea to push this into the scheduler.
>
> The design of dma_fence is that you submit that once and *only* once and
> then get a result for this submission. If re-submission is desirable it
> should be done in userspace or at least higher levels.
Panfrost has an interesting feature where it's possible to rescue a job
during a GPU reset. Because jobs are queued on the GPU if the job hasn't
actually started executing then it's quite possible to safely resubmit
it from the kernel driver and user space doesn't need to be involved.
The benefit of this is if another process has hung the GPU that
processes jobs can be killed off without affecting any other innocent
processes.
One option would be to hide all this from the scheduler, but I can't see
how to do that without also hiding the actual reset from the scheduler.
Admittedly at the moment Panfrost is far too aggressive at resetting and
will perform a GPU reset in conditions where it's completely
unnecessary. There's work to do there but I haven't had the time to look
at it yet.
> Apart from that, yes a NULL check is missing here but that should be
> trivial to fix.
What I'm struggling to get my head round is whether it's correct to
always treat the job as signalled just because s_fence->parent is NULL?
Thanks,
Steve
> Thanks,
> Christian.
>
>>
>> Thanks,
>>
>> Steve
>>
>>> Signed-off-by: Arvind Yadav <Arvind.Yadav@amd.com>
>>> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>> ---
>>>
>>> changes in v1,v2 - Enable signaling for finished fence in sche_main()
>>> is removed
>>>
>>> ---
>>> drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>> index e0ab14e0fb6b..2ac28ad11432 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>> @@ -829,7 +829,7 @@ drm_sched_get_cleanup_job(struct
>>> drm_gpu_scheduler *sched)
>>> job = list_first_entry_or_null(&sched->pending_list,
>>> struct drm_sched_job, list);
>>> - if (job && dma_fence_is_signaled(&job->s_fence->finished)) {
>>> + if (job && dma_fence_is_signaled(job->s_fence->parent)) {
>>> /* remove job from pending_list */
>>> list_del_init(&job->list);
>>> @@ -841,7 +841,7 @@ drm_sched_get_cleanup_job(struct
>>> drm_gpu_scheduler *sched)
>>> if (next) {
>>> next->s_fence->scheduled.timestamp =
>>> - job->s_fence->finished.timestamp;
>>> + job->s_fence->parent->timestamp;
>>> /* start TO timer for next job */
>>> drm_sched_start_timeout(sched);
>>> }
>
next prev parent reply other threads:[~2022-09-29 15:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 16:43 [PATCH v4 0/6] dma-buf: Check status of enable-signaling bit on debug Arvind Yadav
2022-09-14 16:43 ` [PATCH v4 1/6] dma-buf: Remove the signaled bit status check Arvind Yadav
2022-09-14 16:43 ` [PATCH v4 2/6] dma-buf: set signaling bit for the stub fence Arvind Yadav
2022-09-14 16:43 ` [PATCH v4 3/6] dma-buf: Enable signaling on fence for selftests Arvind Yadav
2022-09-14 16:43 ` [PATCH v4 4/6] dma-buf: dma_fence_wait must enable signaling Arvind Yadav
2022-09-15 12:06 ` Christian König
2022-09-14 16:43 ` [PATCH v4 5/6] drm/sched: Use parent fence instead of finished Arvind Yadav
2022-09-29 14:53 ` Steven Price
2022-09-29 14:57 ` Christian König
2022-09-29 15:31 ` Steven Price [this message]
2022-09-29 17:07 ` [Linaro-mm-sig] " Christian König
2022-09-14 16:43 ` [PATCH v4 6/6] dma-buf: Check status of enable-signaling bit on debug Arvind Yadav
2022-09-15 12:06 ` Christian König
2022-09-15 12:07 ` [PATCH v4 0/6] " Christian König
2022-09-15 13:02 ` Yadav, Arvind
2022-09-15 16:05 ` Christian König
2022-09-17 6:17 ` Ville Syrjälä
2022-09-17 15:18 ` [Linaro-mm-sig] " Christian König
2022-09-19 11:26 ` Ville Syrjälä
2022-09-19 11:38 ` 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=ccb55f39-2d7d-1e9d-91ac-70f609370e22@arm.com \
--to=steven.price@arm.com \
--cc=Arunpravin.PaneerSelvam@amd.com \
--cc=Arvind.Yadav@amd.com \
--cc=airlied@linux.ie \
--cc=amaranath.somalapuram@amd.com \
--cc=andrey.grodzovsky@amd.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=shashank.sharma@amd.com \
--cc=sumit.semwal@linaro.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
all inboxes | Powered by JetHome®