[PATCH] drm/amdgpu: reduce the full access time by about 50ms

Zhou, Peng Ju PengJu.Zhou at amd.com
Fri Dec 25 06:34:17 UTC 2020


[AMD Official Use Only - Internal Distribution Only]


Hi Paul

  1.  The 50 ms is the whole full access time reduced, not one msleep(1),

During amdgpu driver init, it will hit msleep(1) several times which increased the total time of full access.



I load amdgpu in the guest VM and collect VF's full access time in the host, host dmesg  was listed in the below:
In this time, the time reduced : 0.236847 s - 0.150411 s = 86.436 ms .
(The reason why it is 80+ms is that I add some code to program one register by psp. )

VF Start Full access
VF exit full access
VF full access time
msleep(1)
295.9031 s
296.0535 s
0.150411 s
usleep_range(10, 100)
658.1791 s
658.4159 s
0.236847 s



  1.  If I only change msleep(1) to usleep_range(10, 100),  the polling time will reduced from 2 seconds to 0.2 seconds,

So I change timeout from "timeout = 2000;" to "timeout = 20000;"



host dmesg  with udelay_range(10, 100) in amdgpu:

[  295.903102] gim info libgv: [4:0:0][amdgv_sched_enter_full_access:877] VF0 entered full access mode.

[  295.906661] gim info libgv: [4:0:0][amdgv_ih_iv_ring_entry_process:254] PF_VF_MSGBUF_ACK received

[  296.052903] gim info libgv: [4:0:0][amdgv_ih_iv_ring_entry_process:192] VF_PF_MSGBUF_VALID received

[  296.052910] gim info libgv: [4:0:0][amdgv_ih_iv_ring_entry_process:205] Received Event: VF0, event = 0x2

[  296.052914] gim info libgv: [4:0:0][amdgv_sched_event_queue_push_ex:193] queue event REL_GPU_INIT(0xef01) for VF0 of block(0xf0)

[  296.052934] gim info libgv: [4:0:0][amdgv_sched_process_event:1582] process event REL_GPU_INIT (0xef01) for VF0 of block (0xf0)

[  296.052944] gim info libgv: [4:0:0][navi12_gpuiov_set_mmsch_vfgate:904] mmsch mb ints disabled schedid = 4

[  296.053334] gim info libgv: [4:0:0][navi12_psp_v11_set_mb_int:632] psp mailbox disabled for VF0

[  296.053513] gim info libgv: [4:0:0][amdgv_sched_exit_full_access:976] VF0 exited full access.



Host demsg with msleep(1) in amdgpu:

[  658.179053] gim info libgv: [4:0:0][amdgv_sched_enter_full_access:877] VF0 entered full access mode.

[  658.182648] gim info libgv: [4:0:0][amdgv_ih_iv_ring_entry_process:254] PF_VF_MSGBUF_ACK received

[  658.415227] gim info libgv: [4:0:0][amdgv_ih_iv_ring_entry_process:192] VF_PF_MSGBUF_VALID received

[  658.415237] gim info libgv: [4:0:0][amdgv_ih_iv_ring_entry_process:205] Received Event: VF0, event = 0x2

[  658.415241] gim info libgv: [4:0:0][amdgv_sched_event_queue_push_ex:193] queue event REL_GPU_INIT(0xef01) for VF0 of block(0xf0)

[  658.415299] gim info libgv: [4:0:0][amdgv_sched_process_event:1582] process event REL_GPU_INIT (0xef01) for VF0 of block (0xf0)

[  658.415311] gim info libgv: [4:0:0][navi12_gpuiov_set_mmsch_vfgate:904] mmsch mb ints disabled schedid = 4

[  658.415719] gim info libgv: [4:0:0][navi12_psp_v11_set_mb_int:632] psp mailbox disabled for VF0

[  658.415900] gim info libgv: [4:0:0][amdgv_sched_exit_full_access:976] VF0 exited full access.





----------------------------------------------------------------------
BW
Pengju Zhou




-----Original Message-----

From: Paul Menzel <pmenzel at molgen.mpg.de<mailto:pmenzel at molgen.mpg.de>>

Sent: Friday, December 25, 2020 6:44 AM

To: Zhou, Peng Ju <PengJu.Zhou at amd.com<mailto:PengJu.Zhou at amd.com>>

Cc: amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>; Deucher, Alexander <Alexander.Deucher at amd.com<mailto:Alexander.Deucher at amd.com>>; Koenig, Christian <Christian.Koenig at amd.com<mailto:Christian.Koenig at amd.com>>

Subject: Re: [PATCH] drm/amdgpu: reduce the full access time by about 50ms



Dear Peng Ju,





Thank you for your patch.



Am 24.12.20 um 07:04 schrieb pengzhou:



Could you please configure your name in git:



     git config --global user.name "Peng Zhou" # or Peng Ju Zhou



Also, please mention PSP in some way in the git commit message summary.

Maybe:



> drm/amdgpu: Reduce delay in PSP command submit by ...



> The function msleep(1) can be delay to 10+ ms sometimes, which

> contributes a big delay during the full access time.



Do you have the Linux log messages with timestamps, where the delay can be seen?



> Changing msleep(1) to usleep_range(10, 100) and it can reduce about

> 50ms delay during full access time.



(Please wrap lines after 75 characters.)



`usleep_range(10, 100)` is 100 μs which is less then 1 ms (= 1.000 μs).

What datasheet specifies the needed delays?



> Signed-off-by: pengzhou <PengJu.Zhou at amd.com<mailto:PengJu.Zhou at amd.com>>

> Change-Id: I151a07c55068d5c429553ef0e6668f024c0c0f3d

> ---

>   drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-

>   1 file changed, 1 insertion(+), 1 deletion(-)

>

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

> index 523d22db094b..ef69051681cf 100644

> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

> @@ -282,7 +282,7 @@ psp_cmd_submit_buf(struct psp_context *psp,

>                           ras_intr = amdgpu_ras_intr_triggered();

>                           if (ras_intr)

>                                         break;

> -                        msleep(1);

> +                       usleep_range(10, 100);



With `timeout = 2000`, this was a maximum of two seconds (or even 20 seconds judging from your commit message). With your change it seems the waiting time is reduced to 0.2 seconds.



I do not understand, how you reach 50 ms in the commit message title?

Only if the msleep would take 50 ms, which is unlikely.



>                           amdgpu_asic_invalidate_hdp(psp->adev, NULL);

>            }



It's great to see these kind of optimizations, as amdgpu takes 400 ms to load on my system.



In a followup the logging should be improved too. Maybe, print a warning, should it take longer than five milliseconds.



I tested that it still boots on my MSI B350M MORTAR (MS-7A37) with AMD Ryzen 3 2200G, but couldn't determine if the patch improved the boot time in anyway due to absent logging.





Kind regards,



Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20201225/cf84a299/attachment-0001.htm>


More information about the amd-gfx mailing list