On Mon 2025-07-07 20:02:13, Sasha Levin wrote: > From: Mario Limonciello > > [ Upstream commit 12ffc3b1513ebc1f11ae77d053948504a94a68a6 ] > > Currently swap is restricted before drivers have had a chance to do > their prepare() PM callbacks. Restricting swap this early means that if > a driver needs to evict some content from memory into sawp in it's > prepare callback, it won't be able to. > > On AMD dGPUs this can lead to failed suspends under memory pressure > situations as all VRAM must be evicted to system memory or swap. > > Move the swap restriction to right after all devices have had a chance > to do the prepare() callback. If there is any problem with the sequence, > restore swap in the appropriate dpm resume callbacks or error handling > paths. > > Closes: https://github.com/ROCm/ROCK-Kernel-Driver/issues/174 > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2362 > Signed-off-by: Mario Limonciello > Tested-by: Nat Wittstock > Tested-by: Lucian Langa > Link: https://patch.msgid.link/20250613214413.4127087-1-superm1@kernel.org > Signed-off-by: Rafael J. Wysocki > Signed-off-by: Sasha Levin > --- > > **YES** > > This commit should be backported to stable kernel trees for the > following reasons: > > ## Critical Bug Fix for Real User Issues > > 1. **Fixes Actual Suspend Failures**: The commit addresses real-world > suspend failures under memory pressure on systems with AMD discrete > GPUs. The linked issues (ROCm/ROCK-Kernel-Driver#174 and > freedesktop.org/drm/amd#2362) indicate this affects actual users. > > 2. **Regression Fix**: This is effectively a regression fix. The PM > subsystem's early swap restriction prevents AMD GPU drivers from > properly evicting VRAM during their prepare() callbacks, which is a > requirement that has become more critical as GPU VRAM sizes have > increased. Stop copying AI generated nonsense to your emails while making it look you wrote that. When did this regress? Pavel -- I don't work for Nazis and criminals, and neither should you. Boycott Putin, Trump, and Musk!