Re:Systemd 248 RC3: systemd-oomd is now considered fully sup...
by pedrocr on Sunday March 14, 2021 @08:14AM
(#26454680)
For 2) last time I looked I couldn't find a way to have a memory contract with the kernel that allowed for a given allocation to be evicted at will by the kernel while also telling the application that has happened. This would be ideal for apps that can grow their cache unbounded (e.g., photo processing apps with each photo, browsers with each tab) but can also regenerate that cache at will. You end up having tunables for how much cache to hold in RAM which is never correct as depending on what else the user is doing there may be a lot or very little free RAM.
[ Parent
| on HN ]
Re:Systemd 248 RC3: systemd-oomd is now considered fully sup...
by the8472 on Sunday March 14, 2021 @08:25AM
(#26454737)
You can use PSI for that. And it actually makes more sense when all applications listen on the global PSI indicators so that if one application would start thrashing another can free up memory cooperatively. But if needed it can also be done per cgroup.
Re:Systemd 248 RC3: systemd-oomd is now considered fully sup...
by nitrogen on Sunday March 14, 2021 @12:22PM
(#26456532)
Something like madvise(MADV_FREE) sounds closer than MADV_DONTNEED -- the app can check for zero where it wrote nonzero -- but doesn't guarantee the freeing will be delayed until there is memory pressure.