Created attachment 131223 [details] HTML page generated by pm-graph (`sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg`) The ASRock E350M1 has a Radeon HD 6310. ``` $ sudo lspci -s 0:01.0 -nn -v 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at e0000000 (32-bit, prefetchable) [size=256M] I/O ports at 2000 [size=256] Memory at f0100000 (32-bit, non-prefetchable) [size=256K] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: radeon Kernel modules: radeon ``` With Debian Sid/unstable with Linux 4.9.25 suspend and resume times are benchmarked with pm-graph [1], and the command below. ``` sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg ``` It turns out that with 258 ms the radeon module takes the majority of the time during suspend. In that cycle one `radeon_bo_evict_vram` call takes the longest with 198 ms. ``` […] 459.186778 | 0) kworker-1495 | 0.974 us | radeon_fence_wait_empty [radeon](); 459.186780 | 0) kworker-1495 | 0.440 us | radeon_fence_wait_empty [radeon](); 459.186783 | 0) kworker-1495 | 0.501 us | radeon_fence_wait_empty [radeon](); 459.186785 | 0) kworker-1495 | 5.424 us | radeon_save_bios_scratch_regs [radeon](); 459.186793 | 0) kworker-1495 | 7625.511 us | evergreen_suspend [radeon](); 459.194422 | 0) kworker-1495 | 10.158 us | evergreen_hpd_fini [radeon](); 459.194434 | 0) kworker-1495 | 198203.3 us | radeon_bo_evict_vram [radeon](); […] ``` Please see the attached files for more details.
Created attachment 131224 [details] ftrace messages generated by pm-graph (`sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg`)
That is expected. During suspend we need to backup VRAM and that can be multiple gigs of memory.
(In reply to Christian König from comment #2) > That is expected. During suspend we need to backup VRAM and that can be > multiple gigs of memory. The board has the Fusion APU E-350, which is not external card, and which uses the “normal system memory”, right? So I wonder what needs to be backed up?
Ah, sorry! Yes that is a known issue on APUs. See the comment in radeon_bo_evict_vram(): /* late 2.6.33 fix IGP hibernate - we need pm ops to do this correct */ if (0 && (rdev->flags & RADEON_IS_IGP)) { if (rdev->mc.igp_sideport_enabled == false) /* Useless to evict on IGP chips */ return 0; } return ttm_bo_evict_mm(&rdev->mman.bdev, TTM_PL_VRAM); The problem is the driver doesn't know if we are suspending or hibernating. For pure suspending (when system memory is still being refreshed) you don't need to evict VRAM on APUs. But for hibernating (when system memory is written to disk) you need to evict VRAM because the normal OS doesn't know about it and won't back it up.
For the record, bug #107277 [1] is the same for amdgpu (like Raven devices. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=107277
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/798.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.