morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-14 00:14:32 +09:00
Code Issues Packages Projects Releases Wiki Activity

docs: Update MEMORY_PRESSURE to mention recent improvements in GLib

Browse Source 
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>
This commit is contained in:
Philip Withnall
2025-11-02 11:34:03 +00:00
committed by Zbigniew Jędrzejewski-Szmek
parent 0712316e8e
commit 69f1a1d5ed
1 changed files with 10 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/MEMORY_PRESSURE.md
View File

@@ -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.