Discussion:
how to make systemd ignore the memory cgroup controller and hierarchy
(too old to reply)
Lennart Poettering
2018-05-10 15:05:43 UTC
Permalink
Raw Message
I have the memory cgroup controller configured in the kernel. I want to use it
myself directly without interference from systemd.
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).
Well, since on cgroupsv1 the hierachies are exposes in a mostly
independent way you should be able to get away with using them
directly if you make sure systemd will otherwise not use them.

Lennart
--
Lennart Poettering, Red Hat
john terragon
2018-05-10 15:01:05 UTC
Permalink
Raw Message
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
Lennart Poettering
2018-05-10 15:07:30 UTC
Permalink
Raw Message
Post by john terragon
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?
No, the issue is still open. I'd be happy to review a patch for that!

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2018-05-10 15:04:45 UTC
Permalink
Raw Message
Hi.
I have the memory cgroup controller configured in the kernel. I want
to use it myself directly without interference from systemd. I tried
setting DefaultMemoryAccounting=no in system.conf but systemd seems
to still interfere with the hierarchy for the memory controller
(e.g. systemctl daemon-reload for some reason removes all tasks from
my subgroups in the memory hierarchy). Since none of the cgroup
controllers are strictly needed by systemd (only the basic cgroup
infrastructure in the kernel is neede. The single controllers could
be disabled, if I'm not mistaken.) how do I get systemd to leave the
memory controller and relative hierarchy alone?
It leaves all hierarchies alone which aren't used by at least one of
the units it manages. Hence: if systemd is using the memory controller
on your system try to figure out which unit is causing this.

Currently there's no nice way to debug this, except maybe watching
inotify events on /sys/fs/cgroup to see why sets of cgroups systemd
precisely creates.

Other than that you might want to look for any unit that has
MemoryAccounting= set, or any a memory limit enforced, or delegation
turned on.

Lennart
--
Lennart Poettering, Red Hat
Loading...