[RFC 0/2] Evict VRAM after processes are frozen

[Mario Limonciello <superm1@kernel.org>]

From: Mario Limonciello <mario.limonciello@amd.com>

As part of the suspend and hibernate sequences devices supported
by amdgpu will have VRAM evicted.  This has been littered with problems
in the past, and now it is called strategically at multiple times
during power management sequences.

Most recently there were a number of issues reported that were root caused
to physical memory pressure at suspend time where VRAM couldn't be evicted.
A new call was introduced using a PM notifier before swap was turned off
so that even if there are physical memory pressures VRAM could still be
evicted into swap.

This helped, but users using older systemd noted that this could lead to a
deadlock.  This is because user processes aren't frozen by older versions
of systemd and thus if a game is running it could potentially be creating
BOs during the eviction thus preventing eviction from ever completing.

This isn't an issue with newer systemd because it uses cgroup freezing
to freeze user processes. Nonetheless this isn't a good behavior to rely
upon for userspace, so this series aims to solve the problem in another way.

Introduce new PM notifier calls after "prepare" notifier is done AND after
tasks have been frozen.  amdgpu listens to these PM notifier calls and
will run the first eviction at this time.

Mario Limonciello (2):
  PM: Add suspend and hibernate notifications for after freeze
  drm/amd: Use suspend and hibernate post freeze notifications

 Documentation/driver-api/pm/notifiers.rst  | 19 ++++++++++++++++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 ++--
 include/linux/suspend.h                    | 14 ++++++++------
 kernel/power/hibernate.c                   |  9 +++++++--
 kernel/power/suspend.c                     | 13 +++++++++----
 5 files changed, 42 insertions(+), 17 deletions(-)

-- 
2.43.0