[systemd-devel] Confining ALL processes to a CPUs/RAM via cpuset controller

[Lennart Poettering]

On Wed, 20.07.16 14:49, Daniel P. Berrange (berrange at redhat.com) wrote:

> > > The key factor here is use of "Before" to ensure this gets run immediately
> > > after systemd switches root out of the initrd, and before /any/ long lived
> > > services are run. This lets us set cpuset placement on systemd (pid 1)
> > > itself and have that inherited by everything it spawns. I felt this is
> > > better than trying to move processes after they have already started,
> > > because it ensures that any memory allocations get taken from the right
> > > NUMA node immediately.
> > >
> > > Empirically this approach seems to work on Fedora 23 (systemd 222) and
> > > RHEL 7 (systemd 219), but I'm wondering if there's any pitfalls that I've
> > > not anticipated here.
> > 
> > Yes, PID 1 was moved to the special scope unit init.scope as mentioned
> > above (in preparation for cgroupsv2 where inner cgroups can never
> > contain PIDs). This is likely going to break then.
> 
> cgroupsv2 is likely to break many things once distros switch over, so
> I assume that wouldn't be done in a minor update - only a major new
> distro release so, not so concerning.

To keep things obvious we also moved PID 1 into init.scope on
cgroupsv1 systems.

Hence, your script might already break as soon as you update to a more
recent systemd version, regardless if cgroupsv1 or cgroupsv2 are used.

> > But again, I have the suspicion that CPUAffinity= might already
> > suffice for you?
> 
> Yep, it looks like it should suffice for most people, unless they also
> wish to have memory node restrictions enforced from boot.

I'd be open to adding some sane subset of numactl as friendly
high-level options to systemd too. As my knowledge of NUMA (and access
to systems with NUMA) is pretty limited, we#d need a contributor patch
for that however.

Lennart

-- 
Lennart Poettering, Red Hat