On Wed, 20.07.16 14:49, Daniel P. Berrange (berra...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel