[RFC] systemd-journald, mmap-cache, and its ENOMEM-driven window reclamation

[Vito Caputo <vcaputo@xxxxxxxxxxx>]

Hello list,

I'd like to have a conversation about the robustness of the
ENOMEM-based mmap-cache window reclamation. [0]

Isn't this arguably a partial implementation, when any other
in-process ENOMEM trigger, outside the purvue of mmap-cache, doesn't
invoke the same reclaim machinery and retry before failing the
operation?

Shouldn't we, at least within the systemd-journald process, have _all_
ENOMEM-capable paths be reclaim aware?  Though arguably most likely,
there's no guarantee that exhaustion will always occur via
mmap_cache_get().

I doubt it would be feasible to achieve anything of this sort on
behalf of external sd-journal consumers, since C doesn't really expose
ways of transparently hooking into the allocator.  Maybe glibc
actually has features in this regard I'm unaware of?  Even if it does,
there's still syscalls failing on ENOMEM which might succeed on a
retry post-reclaim, no?

For 100% systemd-internal code, doesn't it seem like we could be doing
more here?  As in, maybe providing a global runtime hook for a memory
reclaimer, and having all ENOMEM return paths wrapped in a reclaim and
retry attempt before propagating out the often fatal ENOMEM error?

Regards,
Vito Caputo

[0] https://github.com/systemd/systemd/blob/v247/src/journal/mmap-cache.c#L410
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel