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

[John Haxby]

On 12/09/14 16:03, Kay Sievers wrote:
> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby <john.haxby at oracle.com> wrote:
>> 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?
> 
> As explained several times, there is no point in mis-using udev to
> unconditionally react to kernel events to trigger things in the kernel
> again. That is not how driver/device binding works for all the other
> subsystems on Linux.
> 

I can't find an explanation, just "this is not going to happen".  Also,
we are proposing a mechanism by which a policy for deciding whether CPUs
should be placed on line can be implemented.   Possible choices range
from "no, not yet" (more-or-less the above) through licensing
constraints, topological considerations all the way to "just give me
everything".  We have to pick something for the default and probably the
least surprising for the end user is just to bring the CPU on line.  The
present behaviour is perhaps the most surprising: completely ignore
hot-plugged CPUs.


>> I'm hoping you have another place in mind.
> 
> The kernel itself or any other custom facility. This stuff has no
> place in default/upstream udev, it is the wrong way to do things in
> default setups.

So we need to introduce yet another mechanism for one particular class
of hotplug device?   I must admit I'm at a loss to see why hotplug CPUs
are so different for everything else that can be hotplugged.

Could you explain why udev shouldn't do this and what makes hotplug CPUs
so different?    I must be missing something really obvious here.


> 
>> 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.
> 
> Udev does not decide which device show up, it just classifies stuff
> that processes events.

That's what I don't understand.

Let's say I plug in a USB printer.  Looking through the udev rules on my
machine I see

    SUBSYSTEM=="printer", TAG+="systemd"
       ENV{SYSTEMD_WANTS}+="printer.target"

(line split for readability).    A whileback I proposed

   ACTION==“add” KERNEL==“cpu[0-9]*” TAG+="systemd"
       ENV{SYSTEMD_WANTS}+=“cpuadd.service”

Aside from the obvious syntactic differences, what's the difference
between these?

Does it make any difference if the default is not to bring online more
CPUs that the system booted with?  Or some other clever default?

Why does the kernel not bring CPUs online automatically?  This must have
come up before, and what you have been saying seems to suggest that
there is something going on here that I am just missing.

jch

PS I'm not (yet) subscribed to systemd-devel, please make sure you keep
the cc's.