From: Philip Withnall Date: Sun, 2 Nov 2025 11:34:03 +0000 (+0000) Subject: docs: Update MEMORY_PRESSURE to mention recent improvements in GLib X-Git-Tag: v259-rc1~9 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=69f1a1d5eda4d4f181396704c5d6c89c96640829;p=thirdparty%2Fsystemd.git 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 --- diff --git a/docs/MEMORY_PRESSURE.md b/docs/MEMORY_PRESSURE.md index 84ba1fad4da..17aa38689e2 100644 --- 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.