docs: Update MEMORY_PRESSURE to mention recent improvements in GLib

See https://gitlab.gnome.org/GNOME/glib/-/issues/2931 for the changes in
GLib upstream. Using `GMemoryMonitor` is now more compliant with the
systemd recommended approach, but it needs further work to read the
recommended environment variables rather than unconditionally accessing
the per-cgroup PSI kernel file directly.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

diff --git a/docs/MEMORY_PRESSURE.md b/docs/MEMORY_PRESSURE.md
index 84ba1fad4da54b09ee26985077f113e05a2edb38..17aa38689e2cefaef852773693839cc459e3d7d6 100644 (file)
--- a/docs/MEMORY_PRESSURE.md
+++ b/docs/MEMORY_PRESSURE.md
@@ -227,12 +227,15 @@ handling, it's typically sufficient to add a line such as:
 
 Other programming environments might have native APIs to watch memory
 pressure/low memory events. Most notable is probably GLib's
-[GMemoryMonitor](https://docs.gtk.org/gio/iface.MemoryMonitor.html). It
-currently uses the per-system Linux PSI interface as the backend, but operates
-differently than the above: memory pressure events are picked up by a system
-service, which then propagates this through D-Bus to the applications. This is
-typically less than ideal, since this means each notification event has to
-traverse three processes before being handled. This traversal creates
+[GMemoryMonitor](https://docs.gtk.org/gio/iface.MemoryMonitor.html). As of GLib
+2.86.0, it uses the per-cgroup PSI kernel file to monitor for memory pressure,
+but does not yet read the environment variables recommended above.
+
+In older versions, it used the per-system Linux PSI interface as the backend, but operated
+differently than the above: memory pressure events were picked up by a system
+service, which then propagated this through D-Bus to the applications. This was
+typically less than ideal, since this means each notification event had to
+traverse three processes before being handled. This traversal created
 additional latencies at a time where the system is already experiencing adverse
-latencies. Moreover, it focuses on system-wide PSI events, even though
+latencies. Moreover, it focused on system-wide PSI events, even though
 service-local ones are generally the better approach.