[systemd-devel] Relationship between cgroup hierarchy and slice names

Yeongjin Kwon yeongjinkwon at gmail.com
Wed May 11 23:34:14 UTC 2022


On Tue, May 10, 2022 at 8:48 AM Lennart Poettering
<lennart at poettering.net> wrote:
> But how would it even work? if you say "everything in foo.slice should
> now be in bar.slice". but once you say it, these units would be in
> bar.slice so the rule doesn't apply anymore... it's messy to use a
> property as matching parameter that is also the parameter you want to
> change, because then things cannot possibly be declarative/idempotent
> anymore...

I see. I had a feeling this would be impractical anyways, but I wanted
to know if it was possible. Thank you for the feedback.

On Tue, May 10, 2022 at 7:47 AM Michal Koutný <mkoutny at suse.com> wrote:
> I'm wondering is the certain slice or its parent any of the systemd
> implicit slices ({user,user-,system,machine}.slice,...)?
>
> Or you just want to override a hierarchy defined by some 3rd party
> units (perhaps with a purpose)?

I was trying to override the cgroup hierarchy for the units made by
the KDE plasma desktop environment to better implement resource
control of the desktop environment and applications. The units were
the system unit session-*.scope (located directly under user-*.slice)
and the user units background.slice and session.slice (under
user@*.service). I thought that by having all of these units under one
slice that was reserved for the desktop environment, it would be
easier to add resource protections (memory, cpu, etc.) to the desktop
environment as a whole. But considering how complicated it is to
override the hierarchy, I settled on a solution that does not require
reorganizing the cgroup hierarchy.

Yeongjin Kwon


More information about the systemd-devel mailing list