[systemd-devel] [PATCH] Add the CPU hotplug rule

John Haxby john.haxby at oracle.com
Fri Sep 12 06:04:49 PDT 2014


On 02/09/14 16:42, Kay Sievers wrote:
>> > Either the kernel has to provide a mechanism for the userspace to
>> > control onlining, or do it itself and provide a mechanism to prevent
>> > automatic onlining. I think that the first option is actually
>> > cleaner. So yeah, let's add the original rule which does it
>> > unconditionally,
> No, as outlined already, we are not doing this. It is just wrong.
> 
>> > and people who have too many cpus and have special
>> > needs can provide a custom udev rule which does something different.
>> >
>> > cpuadd.service or cpuadd at .service seem overkill, since the one we
>> > would provide would still do the exact same thing: unconditionally
>> > enable the CPU.
> Nothing wrong with that, if people need that. But this can for sure
> not live in systemd/udev, it is not the right place.

Kay, I've worked on a case with Xen domUs which have only some of their
virtual CPUs online at any given time. This deployment has scripts which
only turn up extra CPUs when one of the applications has to do a
failover from one virtual machine to another. The point is that needed
CPU hotplug behaviour is not necessarily uniform to everyone.

Even if the default, out of the box, behaviour is to turn up the CPUs
unconditionally, udev seems the best place to change this behaviour at
runtime. The fact that CPUs can be hotplugged at all should imply that
some users will need different behaviour than others. Here, the default
action is almost a trivial configuration... but not the only possible
desired configuration.

Can I ask your reasoning for CPU hotplug behaviour not being the role of
udev to fulfill? If that's not the right place, where do you believe
would be the appropriate alternative?

I'm hoping you have another place in mind. When I think of changing the
behaviour of any removable hardware, udev is automatically where I look
first. So if I'm missing something here, I would really like some more
input.


More information about the systemd-devel mailing list