[systemd-devel] how to make systemd ignore the memory cgroup controller and hierarchy

john terragon terragonjohn at yahoo.com
Thu May 10 15:01:05 UTC 2018


 
  On Wednesday, May 9, 2018, 10:02:14 PM GMT+2, Simon McVittie <smcv at collabora.com> wrote: 

>I don't think this is supported. systemd behaves as though cgroups v2 is
>in use (single unified cgroup hierarchy) even if you are currently using
>cgroups v1 (one parallel hierarchy per controller).


According to this

https://github.com/systemd/systemd/issues/7624
they seemed to agree to change the behavior of DefaultMemoryAccounting so that, if set to "never", systemd should leave the memory controller alone. Did they implement it?

For my desktop (or laptop) system I need to implement this simple memory resource management:
1) there are two cgroups for the memory controller (globally): swappable, nonswappable.
2) in swappable, I have memory.swappiness=100
3) in nonswappable I have memory.swappiness=0 and the oom killer disabled
4) I use cgsendrules to classify 
         a) all the swappables (e.g. firefox) with specific rules
         b) all the unswappables with a last catch-all rule.

I don't know if anyone else has experienced this but in a normal desktop setting even with a decent amount of RAM, when the kernel starts to hit the swap it's going to try to swap pages from all the wrong processes, as far as desktop usage goes, like X, all the pieces of kde etc. Everything starts stuttering for seconds at a time in the best scenario and for minutes in the worst one (and with an SSD!). 
I've tested the simple scheme above and it completely solves all my issues, the memory hogs get their pages swapped and the rest of the processes stay in memory and everything is smooth as butter.

If this scheme could be implemented with systemd I'd be fine using it also for the memory controller. But otherwise I need to
implement it myself. But, as I said, sometimes systemd seems to move processes from my memory cgroups. 

John

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180510/e3736e68/attachment.html>


More information about the systemd-devel mailing list