cgroups V2: support available?

[Ablu]

Hi!

Systemd is quite ubiquitous nowadays. However, it looks like the cgroups module is not loaded under systemd due to incompatibilities. Now, I see that devlib has a cgroups2 module where the module documentation reads^1 like it may work with systemd.

Is there any way to use this with lisa? There does not seem to be much of documentation on how to use cgroups2 and the code structure looks quite different. So I am not really sure where to get started on integrating it with lisa.

[douglas-raillard-arm]

Hi there,

So the current state of affairs is:

• cgroups devlib module is basically deprecated. I don't recommend using it at all
• cgroups2 is the new module that we added last year. The 2 means it's the successor to cgroups, but it handles both cgroups v1 and v2.
• cgroups2 provides a unified API for both v1 and v2, so that the same client code can be used for both. In practice, that API looks like the v2 interface, and does all the legwork to convert this to an equivalent set of v1 hierarchies. The abstraction also lets you manipulate the resulting hierarchy(ies) after the groups are built (e.g. to add a process).
• The main limitation of cgroups2 I'm aware of is the lack of abstraction for the freezer feature. In v1, this was a controller, but in v2 it's not a controller anymore (it's the cgroup.freeze core interface file), so this was left for future work.

There is a basic example in the module-level docstring: https://github.com/ARM-software/devlib/blob/e012b175c672df84cabf5cc22510b2848b91b399/devlib/module/cgroups2.py#L16

The general idea is that you specify how your hierarchy should look like and what controller you want to enable along with their settings, and then you use the setup_hierarchy() method as a context manager to make it happen.

Note that due to how cgroups work (unrelated to devlib or LISA), you basically need a single owner of the hierarchy. If you use systemd, then that is systemd. However, systemd can give you a subtree in which you are free to do what you want, and that is what the cgroups2 devlib module does. The main implication of that is that the cgroups2 API can never guarantee you that the root of your request is the actual root group (also you could run in e.g. a container anyway, so it can never be really guaranteed).

Since that module hasn't been used extensively since it was contributed, let me know if you find any problem with it.

[Ablu]

There is a basic example in the module-level docstring: https://github.com/ARM-software/devlib/blob/e012b175c672df84cabf5cc22510b2848b91b399/devlib/module/cgroups2.py#L16

Hm. I failed to match that to what happened in /home/ablu/projects/lisa/ipynb/deprecated/energy/EnergyModel_ClusterEnergy.ipynb (which I was trying to resurrect). But I will try again tomorrow just using it as drop-in for cgroups[1]. I will probably need to have a second pass on how these module loading magic works :).

Freeze would be nice, but I can just call systemctl freeze if something annoys me for now :).

Thanks a lot!

[douglas-raillard-arm]

Hm. I failed to match that to what happened in /home/ablu/projects/lisa/ipynb/deprecated/energy/EnergyModel_ClusterEnergy.ipynb (which I was trying to resurrect).

I see, quite the archeological adventure you have there. The API of cgroups and cgroups2 is quite different and cgroups2 is not a drop-in replacement (otherwise we would just have updated the existing cgroups module). Let me know if you face further difficulties.

I will probably need to have a second pass on how these module loading magic works :).

Basically devlib has some classes that are instantiated and stored as Target attributes. In LISA, we make that process lazy so accessing the attribute triggers the instantiation to avoid initializing modules that won't be used.

[douglas-raillard-arm]

You might want to have a look at that, as this notebook dates from the before the deep rework of most LISA APIs: https://lisa-linux-integrated-system-analysis.readthedocs.io/en/latest/changes.html#transitioning-from-lisa-legacy

[douglas-raillard-arm]

Closing as we are migrating the repo to GitLab. New messages on this conversation should be posted at https://gitlab.arm.com/tooling/lisa/-/issues/2172

Note that you can login with your GitHub account on gitlab.arm.com so it should be painless.