* [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 @ 2021-12-09 10:23 Christian König 2021-12-10 9:06 ` [Nouveau] " Thorsten Leemhuis ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Christian König @ 2021-12-09 10:23 UTC (permalink / raw) To: dmoulding, sf, bskeggs; +Cc: nouveau, dri-devel Always waiting for the exclusive fence resulted on some performance regressions. So try to wait for the shared fences first, then the exclusive fence should always be signaled already. v2: fix incorrectly placed "(", add some comment why we do this. Signed-off-by: Christian König <christian.koenig@amd.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +++++++++++++------------ 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 05d0b3eb3690..0ae416aa76dc 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool e if (ret) return ret; - } - fobj = dma_resv_shared_list(resv); - fence = dma_resv_excl_fence(resv); + fobj = NULL; + } else { + fobj = dma_resv_shared_list(resv); + } - if (fence) { + /* Waiting for the exclusive fence first causes performance regressions + * under some circumstances. So manually wait for the shared ones first. + */ + for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) { struct nouveau_channel *prev = NULL; bool must_wait = true; + fence = rcu_dereference_protected(fobj->shared[i], + dma_resv_held(resv)); + f = nouveau_local_fence(fence, chan->drm); if (f) { rcu_read_lock(); @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool e if (must_wait) ret = dma_fence_wait(fence, intr); - - return ret; } - if (!exclusive || !fobj) - return ret; - - for (i = 0; i < fobj->shared_count && !ret; ++i) { + fence = dma_resv_excl_fence(resv); + if (fence) { struct nouveau_channel *prev = NULL; bool must_wait = true; - fence = rcu_dereference_protected(fobj->shared[i], - dma_resv_held(resv)); - f = nouveau_local_fence(fence, chan->drm); if (f) { rcu_read_lock(); @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool e if (must_wait) ret = dma_fence_wait(fence, intr); + + return ret; } return ret; -- 2.25.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-09 10:23 [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 Christian König @ 2021-12-10 9:06 ` Thorsten Leemhuis 2021-12-11 9:59 ` Stefan Fritsch 2021-12-20 19:17 ` Dan Moulding 2 siblings, 0 replies; 8+ messages in thread From: Thorsten Leemhuis @ 2021-12-10 9:06 UTC (permalink / raw) To: Christian König, dmoulding, sf, bskeggs; +Cc: nouveau, dri-devel Hi, this is your Linux kernel regression tracker speaking. On 09.12.21 11:23, Christian König wrote: > Always waiting for the exclusive fence resulted on some performance > regressions. So try to wait for the shared fences first, then the > exclusive fence should always be signaled already. > > v2: fix incorrectly placed "(", add some comment why we do this. > > Signed-off-by: Christian König <christian.koenig@amd.com> FWIW: In case you need to send an improved patch, could you please add this (see (¹) below for the reasoning): Link: https://lore.kernel.org/dri-devel/da142fb9-07d7-24fe-4533-0247b8d16cdd@sfritsch.de/ And if the patch is already good to go: could the subsystem maintainer please add it when applying? See (¹) for the reasoning. BTW, these two lines afaics are missing as well: Fixes: 3e1ad79bf661 ("drm/nouveau: always wait for the exclusive fence") Reported-by: Stefan Fritsch <sf@sfritsch.de> Ciao, Thorsten (¹) Long story: The commit message would benefit from a link to the regression report, for reasons explained in Documentation/process/submitting-patches.rst. To quote: ``` If related discussions or any other background information behind the change can be found on the web, add 'Link:' tags pointing to it. In case your patch fixes a bug, for example, add a tag with a URL referencing the report in the mailing list archives or a bug tracker; ``` This concept is old, but the text was reworked recently to make this use case for the Link: tag clearer. For details see: https://git.kernel.org/linus/1f57bd42b77c Yes, that "Link:" is not really crucial; but it's good to have if someone needs to look into the backstory of this change sometime in the future. But I care for a different reason. I'm tracking this regression (and others) with regzbot, my Linux kernel regression tracking bot. This bot will notice if a patch with a Link: tag to a tracked regression gets posted and record that, which allowed anyone looking into the regression to quickly gasp the current status from regzbot's webui (https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The bot will also notice if a commit with a Link: tag to a regression report is applied by Linus and then automatically mark the regression as resolved then. IOW: this tag makes my life a regression tracker a lot easier, as I otherwise have to tell regzbot manually when the fix lands. :-/ #regzbot ^backmonitor: https://lore.kernel.org/dri-devel/da142fb9-07d7-24fe-4533-0247b8d16cdd@sfritsch.de/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-09 10:23 [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 Christian König 2021-12-10 9:06 ` [Nouveau] " Thorsten Leemhuis @ 2021-12-11 9:59 ` Stefan Fritsch 2021-12-14 9:19 ` Christian König 2021-12-20 19:17 ` Dan Moulding 2 siblings, 1 reply; 8+ messages in thread From: Stefan Fritsch @ 2021-12-11 9:59 UTC (permalink / raw) To: Christian König, dmoulding, bskeggs; +Cc: nouveau, dri-devel On 09.12.21 11:23, Christian König wrote: > Always waiting for the exclusive fence resulted on some performance > regressions. So try to wait for the shared fences first, then the > exclusive fence should always be signaled already. > > v2: fix incorrectly placed "(", add some comment why we do this. > > Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Stefan Fritsch <sf@sfritsch.de> Please also add a cc for linux-stable, so that this is fixed in 5.15.x Cheers, Stefan > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +++++++++++++------------ > 1 file changed, 15 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index 05d0b3eb3690..0ae416aa76dc 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool e > > if (ret) > return ret; > - } > > - fobj = dma_resv_shared_list(resv); > - fence = dma_resv_excl_fence(resv); > + fobj = NULL; > + } else { > + fobj = dma_resv_shared_list(resv); > + } > > - if (fence) { > + /* Waiting for the exclusive fence first causes performance regressions > + * under some circumstances. So manually wait for the shared ones first. > + */ > + for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) { > struct nouveau_channel *prev = NULL; > bool must_wait = true; > > + fence = rcu_dereference_protected(fobj->shared[i], > + dma_resv_held(resv)); > + > f = nouveau_local_fence(fence, chan->drm); > if (f) { > rcu_read_lock(); > @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool e > > if (must_wait) > ret = dma_fence_wait(fence, intr); > - > - return ret; > } > > - if (!exclusive || !fobj) > - return ret; > - > - for (i = 0; i < fobj->shared_count && !ret; ++i) { > + fence = dma_resv_excl_fence(resv); > + if (fence) { > struct nouveau_channel *prev = NULL; > bool must_wait = true; > > - fence = rcu_dereference_protected(fobj->shared[i], > - dma_resv_held(resv)); > - > f = nouveau_local_fence(fence, chan->drm); > if (f) { > rcu_read_lock(); > @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool e > > if (must_wait) > ret = dma_fence_wait(fence, intr); > + > + return ret; > } > > return ret; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-11 9:59 ` Stefan Fritsch @ 2021-12-14 9:19 ` Christian König 2021-12-15 22:32 ` [Nouveau] " Ben Skeggs 0 siblings, 1 reply; 8+ messages in thread From: Christian König @ 2021-12-14 9:19 UTC (permalink / raw) To: Stefan Fritsch, dmoulding, bskeggs; +Cc: nouveau, dri-devel Am 11.12.21 um 10:59 schrieb Stefan Fritsch: > On 09.12.21 11:23, Christian König wrote: >> Always waiting for the exclusive fence resulted on some performance >> regressions. So try to wait for the shared fences first, then the >> exclusive fence should always be signaled already. >> >> v2: fix incorrectly placed "(", add some comment why we do this. >> >> Signed-off-by: Christian König <christian.koenig@amd.com> > > Tested-by: Stefan Fritsch <sf@sfritsch.de> Thanks. > > Please also add a cc for linux-stable, so that this is fixed in 5.15.x Sure, but I still need some acked-by or rb from one of the Nouveau guys. So gentle ping on that. Regards, Christian. > > Cheers, > Stefan > >> --- >> drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +++++++++++++------------ >> 1 file changed, 15 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c >> b/drivers/gpu/drm/nouveau/nouveau_fence.c >> index 05d0b3eb3690..0ae416aa76dc 100644 >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >> struct nouveau_channel *chan, bool e >> if (ret) >> return ret; >> - } >> - fobj = dma_resv_shared_list(resv); >> - fence = dma_resv_excl_fence(resv); >> + fobj = NULL; >> + } else { >> + fobj = dma_resv_shared_list(resv); >> + } >> - if (fence) { >> + /* Waiting for the exclusive fence first causes performance >> regressions >> + * under some circumstances. So manually wait for the shared >> ones first. >> + */ >> + for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) { >> struct nouveau_channel *prev = NULL; >> bool must_wait = true; >> + fence = rcu_dereference_protected(fobj->shared[i], >> + dma_resv_held(resv)); >> + >> f = nouveau_local_fence(fence, chan->drm); >> if (f) { >> rcu_read_lock(); >> @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >> struct nouveau_channel *chan, bool e >> if (must_wait) >> ret = dma_fence_wait(fence, intr); >> - >> - return ret; >> } >> - if (!exclusive || !fobj) >> - return ret; >> - >> - for (i = 0; i < fobj->shared_count && !ret; ++i) { >> + fence = dma_resv_excl_fence(resv); >> + if (fence) { >> struct nouveau_channel *prev = NULL; >> bool must_wait = true; >> - fence = rcu_dereference_protected(fobj->shared[i], >> - dma_resv_held(resv)); >> - >> f = nouveau_local_fence(fence, chan->drm); >> if (f) { >> rcu_read_lock(); >> @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >> struct nouveau_channel *chan, bool e >> if (must_wait) >> ret = dma_fence_wait(fence, intr); >> + >> + return ret; >> } >> return ret; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-14 9:19 ` Christian König @ 2021-12-15 22:32 ` Ben Skeggs 2021-12-21 10:11 ` Thorsten Leemhuis 0 siblings, 1 reply; 8+ messages in thread From: Ben Skeggs @ 2021-12-15 22:32 UTC (permalink / raw) To: Christian König Cc: ML nouveau, dmoulding, Stefan Fritsch, Ben Skeggs, ML dri-devel On Tue, 14 Dec 2021 at 19:19, Christian König <ckoenig.leichtzumerken@gmail.com> wrote: > > Am 11.12.21 um 10:59 schrieb Stefan Fritsch: > > On 09.12.21 11:23, Christian König wrote: > >> Always waiting for the exclusive fence resulted on some performance > >> regressions. So try to wait for the shared fences first, then the > >> exclusive fence should always be signaled already. > >> > >> v2: fix incorrectly placed "(", add some comment why we do this. > >> > >> Signed-off-by: Christian König <christian.koenig@amd.com> > > > > Tested-by: Stefan Fritsch <sf@sfritsch.de> > > Thanks. > > > > > Please also add a cc for linux-stable, so that this is fixed in 5.15.x > > Sure, but I still need some acked-by or rb from one of the Nouveau guys. > So gentle ping on that. Acked-by: Ben Skeggs <bskeggs@redhat.com> > > Regards, > Christian. > > > > > Cheers, > > Stefan > > > >> --- > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +++++++++++++------------ > >> 1 file changed, 15 insertions(+), 13 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> index 05d0b3eb3690..0ae416aa76dc 100644 > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, > >> struct nouveau_channel *chan, bool e > >> if (ret) > >> return ret; > >> - } > >> - fobj = dma_resv_shared_list(resv); > >> - fence = dma_resv_excl_fence(resv); > >> + fobj = NULL; > >> + } else { > >> + fobj = dma_resv_shared_list(resv); > >> + } > >> - if (fence) { > >> + /* Waiting for the exclusive fence first causes performance > >> regressions > >> + * under some circumstances. So manually wait for the shared > >> ones first. > >> + */ > >> + for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) { > >> struct nouveau_channel *prev = NULL; > >> bool must_wait = true; > >> + fence = rcu_dereference_protected(fobj->shared[i], > >> + dma_resv_held(resv)); > >> + > >> f = nouveau_local_fence(fence, chan->drm); > >> if (f) { > >> rcu_read_lock(); > >> @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, > >> struct nouveau_channel *chan, bool e > >> if (must_wait) > >> ret = dma_fence_wait(fence, intr); > >> - > >> - return ret; > >> } > >> - if (!exclusive || !fobj) > >> - return ret; > >> - > >> - for (i = 0; i < fobj->shared_count && !ret; ++i) { > >> + fence = dma_resv_excl_fence(resv); > >> + if (fence) { > >> struct nouveau_channel *prev = NULL; > >> bool must_wait = true; > >> - fence = rcu_dereference_protected(fobj->shared[i], > >> - dma_resv_held(resv)); > >> - > >> f = nouveau_local_fence(fence, chan->drm); > >> if (f) { > >> rcu_read_lock(); > >> @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, > >> struct nouveau_channel *chan, bool e > >> if (must_wait) > >> ret = dma_fence_wait(fence, intr); > >> + > >> + return ret; > >> } > >> return ret; > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-15 22:32 ` [Nouveau] " Ben Skeggs @ 2021-12-21 10:11 ` Thorsten Leemhuis 2021-12-21 10:20 ` Christian König 0 siblings, 1 reply; 8+ messages in thread From: Thorsten Leemhuis @ 2021-12-21 10:11 UTC (permalink / raw) To: Ben Skeggs, Christian König Cc: David Airlie, ML nouveau, ML dri-devel, dmoulding, Ben Skeggs, Stefan Fritsch Hi, this is your Linux kernel regression tracker speaking. CCing Dave and Daniel. On 15.12.21 23:32, Ben Skeggs wrote: > On Tue, 14 Dec 2021 at 19:19, Christian König > <ckoenig.leichtzumerken@gmail.com> wrote: >> >> Am 11.12.21 um 10:59 schrieb Stefan Fritsch: >>> On 09.12.21 11:23, Christian König wrote: >>>> Always waiting for the exclusive fence resulted on some performance >>>> regressions. So try to wait for the shared fences first, then the >>>> exclusive fence should always be signaled already. >>>> >>>> v2: fix incorrectly placed "(", add some comment why we do this. >>>> >>>> Signed-off-by: Christian König <christian.koenig@amd.com> >>> >>> Tested-by: Stefan Fritsch <sf@sfritsch.de> >> >> Thanks. >> >>> >>> Please also add a cc for linux-stable, so that this is fixed in 5.15.x >> >> Sure, but I still need some acked-by or rb from one of the Nouveau guys. >> So gentle ping on that. > Acked-by: Ben Skeggs <bskeggs@redhat.com> What's the status of this patch? I checked a few git trees, but either it's not there or it missed it. Reminder, it's a regression already introduced in v5.15, hence all users of the current stable kernel are affected by it, so it would be nice to get the fix on its way now that Ben acked it and Dan tested it. Ciao, Thorsten P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activities wrt to this regression. #regzbot poke >>>> --- >>>> drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +++++++++++++------------ >>>> 1 file changed, 15 insertions(+), 13 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c >>>> b/drivers/gpu/drm/nouveau/nouveau_fence.c >>>> index 05d0b3eb3690..0ae416aa76dc 100644 >>>> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >>>> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >>>> @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >>>> struct nouveau_channel *chan, bool e >>>> if (ret) >>>> return ret; >>>> - } >>>> - fobj = dma_resv_shared_list(resv); >>>> - fence = dma_resv_excl_fence(resv); >>>> + fobj = NULL; >>>> + } else { >>>> + fobj = dma_resv_shared_list(resv); >>>> + } >>>> - if (fence) { >>>> + /* Waiting for the exclusive fence first causes performance >>>> regressions >>>> + * under some circumstances. So manually wait for the shared >>>> ones first. >>>> + */ >>>> + for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) { >>>> struct nouveau_channel *prev = NULL; >>>> bool must_wait = true; >>>> + fence = rcu_dereference_protected(fobj->shared[i], >>>> + dma_resv_held(resv)); >>>> + >>>> f = nouveau_local_fence(fence, chan->drm); >>>> if (f) { >>>> rcu_read_lock(); >>>> @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >>>> struct nouveau_channel *chan, bool e >>>> if (must_wait) >>>> ret = dma_fence_wait(fence, intr); >>>> - >>>> - return ret; >>>> } >>>> - if (!exclusive || !fobj) >>>> - return ret; >>>> - >>>> - for (i = 0; i < fobj->shared_count && !ret; ++i) { >>>> + fence = dma_resv_excl_fence(resv); >>>> + if (fence) { >>>> struct nouveau_channel *prev = NULL; >>>> bool must_wait = true; >>>> - fence = rcu_dereference_protected(fobj->shared[i], >>>> - dma_resv_held(resv)); >>>> - >>>> f = nouveau_local_fence(fence, chan->drm); >>>> if (f) { >>>> rcu_read_lock(); >>>> @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >>>> struct nouveau_channel *chan, bool e >>>> if (must_wait) >>>> ret = dma_fence_wait(fence, intr); >>>> + >>>> + return ret; >>>> } >>>> return ret; >> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-21 10:11 ` Thorsten Leemhuis @ 2021-12-21 10:20 ` Christian König 0 siblings, 0 replies; 8+ messages in thread From: Christian König @ 2021-12-21 10:20 UTC (permalink / raw) To: Thorsten Leemhuis, Ben Skeggs Cc: David Airlie, ML nouveau, ML dri-devel, dmoulding, Ben Skeggs, Stefan Fritsch Am 21.12.21 um 11:11 schrieb Thorsten Leemhuis: > Hi, this is your Linux kernel regression tracker speaking. > > CCing Dave and Daniel. > > On 15.12.21 23:32, Ben Skeggs wrote: >> On Tue, 14 Dec 2021 at 19:19, Christian König >> <ckoenig.leichtzumerken@gmail.com> wrote: >>> Am 11.12.21 um 10:59 schrieb Stefan Fritsch: >>>> On 09.12.21 11:23, Christian König wrote: >>>>> Always waiting for the exclusive fence resulted on some performance >>>>> regressions. So try to wait for the shared fences first, then the >>>>> exclusive fence should always be signaled already. >>>>> >>>>> v2: fix incorrectly placed "(", add some comment why we do this. >>>>> >>>>> Signed-off-by: Christian König <christian.koenig@amd.com> >>>> Tested-by: Stefan Fritsch <sf@sfritsch.de> >>> Thanks. >>> >>>> Please also add a cc for linux-stable, so that this is fixed in 5.15.x >>> Sure, but I still need some acked-by or rb from one of the Nouveau guys. >>> So gentle ping on that. >> Acked-by: Ben Skeggs <bskeggs@redhat.com> > What's the status of this patch? I checked a few git trees, but either > it's not there or it missed it. You missed it. I've pushed it to drm-misc-fixes about 2 hours ago: https://cgit.freedesktop.org/drm/drm-misc/log/?h=drm-misc-fixes Regards, Christian. > > Reminder, it's a regression already introduced in v5.15, hence all users > of the current stable kernel are affected by it, so it would be nice to > get the fix on its way now that Ben acked it and Dan tested it. > > Ciao, Thorsten > > P.S.: As a Linux kernel regression tracker I'm getting a lot of reports > on my table. I can only look briefly into most of them. Unfortunately > therefore I sometimes will get things wrong or miss something important. > I hope that's not the case here; if you think it is, don't hesitate to > tell me about it in a public reply. That's in everyone's interest, as > what I wrote above might be misleading to everyone reading this; any > suggestion I gave thus might sent someone reading this down the wrong > rabbit hole, which none of us wants. > > BTW, I have no personal interest in this issue, which is tracked using > regzbot, my Linux kernel regression tracking bot > (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting > this mail to get things rolling again and hence don't need to be CC on > all further activities wrt to this regression. > > #regzbot poke > >>>>> --- >>>>> drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +++++++++++++------------ >>>>> 1 file changed, 15 insertions(+), 13 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c >>>>> b/drivers/gpu/drm/nouveau/nouveau_fence.c >>>>> index 05d0b3eb3690..0ae416aa76dc 100644 >>>>> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >>>>> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >>>>> @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >>>>> struct nouveau_channel *chan, bool e >>>>> if (ret) >>>>> return ret; >>>>> - } >>>>> - fobj = dma_resv_shared_list(resv); >>>>> - fence = dma_resv_excl_fence(resv); >>>>> + fobj = NULL; >>>>> + } else { >>>>> + fobj = dma_resv_shared_list(resv); >>>>> + } >>>>> - if (fence) { >>>>> + /* Waiting for the exclusive fence first causes performance >>>>> regressions >>>>> + * under some circumstances. So manually wait for the shared >>>>> ones first. >>>>> + */ >>>>> + for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) { >>>>> struct nouveau_channel *prev = NULL; >>>>> bool must_wait = true; >>>>> + fence = rcu_dereference_protected(fobj->shared[i], >>>>> + dma_resv_held(resv)); >>>>> + >>>>> f = nouveau_local_fence(fence, chan->drm); >>>>> if (f) { >>>>> rcu_read_lock(); >>>>> @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >>>>> struct nouveau_channel *chan, bool e >>>>> if (must_wait) >>>>> ret = dma_fence_wait(fence, intr); >>>>> - >>>>> - return ret; >>>>> } >>>>> - if (!exclusive || !fobj) >>>>> - return ret; >>>>> - >>>>> - for (i = 0; i < fobj->shared_count && !ret; ++i) { >>>>> + fence = dma_resv_excl_fence(resv); >>>>> + if (fence) { >>>>> struct nouveau_channel *prev = NULL; >>>>> bool must_wait = true; >>>>> - fence = rcu_dereference_protected(fobj->shared[i], >>>>> - dma_resv_held(resv)); >>>>> - >>>>> f = nouveau_local_fence(fence, chan->drm); >>>>> if (f) { >>>>> rcu_read_lock(); >>>>> @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, >>>>> struct nouveau_channel *chan, bool e >>>>> if (must_wait) >>>>> ret = dma_fence_wait(fence, intr); >>>>> + >>>>> + return ret; >>>>> } >>>>> return ret; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 2021-12-09 10:23 [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 Christian König 2021-12-10 9:06 ` [Nouveau] " Thorsten Leemhuis 2021-12-11 9:59 ` Stefan Fritsch @ 2021-12-20 19:17 ` Dan Moulding 2 siblings, 0 replies; 8+ messages in thread From: Dan Moulding @ 2021-12-20 19:17 UTC (permalink / raw) To: ckoenig.leichtzumerken; +Cc: nouveau, dmoulding, sf, bskeggs, dri-devel Tested-by: Dan Moulding <dmoulding@me.com> Thanks! -- Dan ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-12-21 10:20 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-09 10:23 [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2 Christian König 2021-12-10 9:06 ` [Nouveau] " Thorsten Leemhuis 2021-12-11 9:59 ` Stefan Fritsch 2021-12-14 9:19 ` Christian König 2021-12-15 22:32 ` [Nouveau] " Ben Skeggs 2021-12-21 10:11 ` Thorsten Leemhuis 2021-12-21 10:20 ` Christian König 2021-12-20 19:17 ` Dan Moulding
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).