On Mon, May 1, 2023 at 11:13 AM Felix Kuehling <felix.kuehling@xxxxxxx> wrote:
>
> Am 2023-04-26 um 12:15 schrieb Alex Sierra:
> > Accomplish this by reading the seq number right away instead of sleep
> > for 5us. There are certain cases where the fence is ready almost
> > immediately. Sleep number granularity was also reduced as the majority
> > of the kiq tlb flush takes between 2us to 6us.
> >
> > Signed-off-by: Alex Sierra <alex.sierra@xxxxxxx>
>
> I'm not sure I have authority to give an R-b for this. But the change
> and the explanation sound reasonable to me. Doing the first check before
> waiting is a no-brainer. Reducing the delay can increase CPU usage or
> bus traffic and may be more controversial.
>
The fences should be in system memory, so it shouldn't affect bus
traffic, but there could be more CPU usage. The change seems fine to
me.
Reviewed-by: Alex Deucher <alexander.deucher@xxxxxxx>
> FWIW, this patch is
>
> Acked-by: Felix Kuehling <Felix.Kuehling@xxxxxxx>
>
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 11 ++++-------
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > index a7627cc0118d..9192896239e9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > @@ -377,14 +377,11 @@ signed long amdgpu_fence_wait_polling(struct amdgpu_ring *ring,
> > uint32_t wait_seq,
> > signed long timeout)
> > {
> > - uint32_t seq;
> > -
> > - do {
> > - seq = amdgpu_fence_read(ring);
> > - udelay(5);
> > - timeout -= 5;
> > - } while ((int32_t)(wait_seq - seq) > 0 && timeout > 0);
> >
> > + while ((int32_t)(wait_seq - amdgpu_fence_read(ring)) > 0 && timeout > 0) {
> > + udelay(2);
> > + timeout -= 2;
> > + }
> > return timeout > 0 ? timeout : 0;
> > }
> > /**
