On Sat, 2020-09-12 at 20:53 +0000, Alexey Avramov wrote:
> how much memory that amounts to in the usual scenarios
700M on F32 without any apps started.
That seems like quite a lot. I mean, we get into a similar region of
memory that EarlyOOM would be protecting with no apps started. So with
applications started, you might get higher.
Largest file: (207.9M) /usr/lib/locale/locale-archive
Files list with its sizes:
https://pastebin.com/Hpr6D3Sv
Locking even 250M-300M takes good effect. For example, demo:
https://www.youtube.com/watch?v=vykUrP1UvcI - no freezes with
prelockd and freeze without prelockd
Was that with or without swap? For GNOME some executable code is JITed
javascript and we really need to protect that somehow.
250-300MiB sounds fine to me, though I do wonder how much of that is
really not needed often (e.g. library code only used at startup).
In general, I really prefer the cgroups approach taken with uresourced.
prelockd is a cool experiment and it proves that executable code being
reclaimed and refaulted is a major cause of latency.
But I feel that uresourced is just nicer conceptually. i.e. we first
segment the system into various parts, which is really simple to do
with systemd (everyone is already moving to systemd). And then we
simply ask the kernel for memory and other guarantees for important
parts of the system.
Unfortunately, while KDE is very close to using systemd for login, I
don't think it is ready yet (at least not on F33). So uresourced is
going to be ineffective for KDE for the time being.
On my F32 with a fixed uresourced[1] and increasing memory protection
to 350MiB, my GNOME session only has really minor hangs and only the
first time I do the tail /dev/zero test. This is with swap on an SSD
and EarlyOOM stopped.
Benjamin
[1] Right now there are two small issues that I will fix once beta
freeze is lifted:
- Memory protection is ineffective due to a systemd bug which prevents
my workaround for another issue from working …
- MemoryMin needs to be used for OOM scenarios (rather than MemoryLow)
I'll leave the protected area at 250MiB though as that matches the
initial change request.