From: Felix Kuehling <felix.kuehling@amd.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/ttm: Ignore signaled move fences
Date: Fri, 5 Mar 2021 13:20:09 -0500 [thread overview]
Message-ID: <6626fc4e-3f4b-74bf-c56a-e0bb9b2bafd9@amd.com> (raw)
In-Reply-To: <db49503a-236e-b4a1-e90d-da8ee21d11b4@gmail.com>
It fixed an intermittent failure to allocate page tables in the page
fault handler (turning retry faults into no-retry faults). I'm not sure
if this caused real problems. I think it could potentially result in
fault storms and a failure to report page faults properly. I'm not sure
if it's a regression or was always present. So I'm not sure if it's an
urgent fix.
Regards,
Felix
Am 2021-03-05 um 2:56 a.m. schrieb Christian König:
>
>
> Am 05.03.21 um 02:21 schrieb Felix Kuehling:
>> Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
>>> Am 27.02.21 um 04:45 schrieb Felix Kuehling:
>>>> Move fences that have already signaled should not prevent memory
>>>> allocations with no_wait_gpu.
>>>>
>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> I work on this on Alex's rebased amd-staging-drm-next. Should this go
>> into any other branches?
>
> I have a branch with stuff for 5.13 which I want to push to
> drm-misc-next as soon as 5.12-rc1 is out.
>
> Going to add this one here to that collection as well unless you say
> that this is really a bug fix and we need it earlier.
>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Felix
>>
>>
>>>> ---
>>>> drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>>> index 3a10bebb75d6..de1ec838cf8b 100644
>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>> @@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct
>>>> ttm_buffer_object *bo,
>>>> return 0;
>>>> if (no_wait_gpu) {
>>>> + ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY;
>>>> dma_fence_put(fence);
>>>> - return -EBUSY;
>>>> + return ret;
>>>> }
>>>> dma_resv_add_shared_fence(bo->base.resv, fence);
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Felix Kuehling <felix.kuehling@amd.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/ttm: Ignore signaled move fences
Date: Fri, 5 Mar 2021 13:20:09 -0500 [thread overview]
Message-ID: <6626fc4e-3f4b-74bf-c56a-e0bb9b2bafd9@amd.com> (raw)
In-Reply-To: <db49503a-236e-b4a1-e90d-da8ee21d11b4@gmail.com>
It fixed an intermittent failure to allocate page tables in the page
fault handler (turning retry faults into no-retry faults). I'm not sure
if this caused real problems. I think it could potentially result in
fault storms and a failure to report page faults properly. I'm not sure
if it's a regression or was always present. So I'm not sure if it's an
urgent fix.
Regards,
Felix
Am 2021-03-05 um 2:56 a.m. schrieb Christian König:
>
>
> Am 05.03.21 um 02:21 schrieb Felix Kuehling:
>> Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
>>> Am 27.02.21 um 04:45 schrieb Felix Kuehling:
>>>> Move fences that have already signaled should not prevent memory
>>>> allocations with no_wait_gpu.
>>>>
>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> I work on this on Alex's rebased amd-staging-drm-next. Should this go
>> into any other branches?
>
> I have a branch with stuff for 5.13 which I want to push to
> drm-misc-next as soon as 5.12-rc1 is out.
>
> Going to add this one here to that collection as well unless you say
> that this is really a bug fix and we need it earlier.
>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Felix
>>
>>
>>>> ---
>>>> drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>>> index 3a10bebb75d6..de1ec838cf8b 100644
>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>> @@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct
>>>> ttm_buffer_object *bo,
>>>> return 0;
>>>> if (no_wait_gpu) {
>>>> + ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY;
>>>> dma_fence_put(fence);
>>>> - return -EBUSY;
>>>> + return ret;
>>>> }
>>>> dma_resv_add_shared_fence(bo->base.resv, fence);
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-05 18:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-27 3:45 [PATCH 1/1] drm/ttm: Ignore signaled move fences Felix Kuehling
2021-02-27 3:45 ` Felix Kuehling
2021-03-01 15:09 ` Christian König
2021-03-01 15:09 ` Christian König
2021-03-05 1:21 ` Felix Kuehling
2021-03-05 1:21 ` Felix Kuehling
2021-03-05 7:56 ` Christian König
2021-03-05 7:56 ` Christian König
2021-03-05 18:20 ` Felix Kuehling [this message]
2021-03-05 18:20 ` Felix Kuehling
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=6626fc4e-3f4b-74bf-c56a-e0bb9b2bafd9@amd.com \
--to=felix.kuehling@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.