On Thu, 04.08.16 16:19, Cedric Bosdonnat (cbosdon...@suse.com) wrote: > Hi Lennart and Werner, > > On Wed, 2016-08-03 at 16:56 +0200, Lennart Poettering wrote: > > On Wed, 03.08.16 14:46, Dr. Werner Fink (werner at suse.de) wrote: > > > problem with v228 (and I guess this is also later AFAICS from logs of > > > current git) that repeating CPU hotplug events (offline/online). The > > > root cause is that cpuset.cpus become not restored by machined. > > > Please note that libvirt can not do this as it is not allowed to do > > > so. > > > > This is a limitation of the kernel cpuset interface, and it's one of > > the reasons we do not expose cpusets at all in systemd right > > now. Thankfully, there's an alternative to cpusets, which is the CPU > > affinity controls exposed via CPUAffinity= in systemd, which do much > > of the same, but have less borked semantics. > > > > We'd like to support cpusets directly in systemd, but we don't do this > > as long as the kernel interfaces are as borked as they are. For > > example, cpusets are flushed out entirely currently when the system > > goes through a suspend/resume cycle. > > > > If libvirt has hook-ups with cpuset, then it bypasses systemd for > > that. > > I guess by CPU affinity you mean sched_setaffinity and friends. If that is > the case, then this is constrained by cpuset too as mentioned here: > > http://www.mjmwired.net/kernel/Documentation/cpusets.txt#53 > > As long as the machine.slice cpuset isn't restored after onlining a CPU again, > then libvirt won't be able to set either the affinity or the cpuset if it > contains that CPU. > > May be the kernel's behaviour is weird and can be discussed, but libvirt can't > do anything on that bug.
Yeah, to make this clear: I do not blame libvirt for this borkedness at all. I blame the kernel. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
