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

[John Haxby]

On 02/09/14 09:42, Colin Guthrie wrote:
> Kay Sievers wrote on 02/09/14 09:27:
>> On Tue, Sep 2, 2014 at 10:01 AM, John Haxby <john.haxby at oracle.com> wrote:
>>>
>>> On 2 Sep 2014, at 06:55, Kay Sievers <kay at vrfy.org> wrote:
>>>
>>>> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
>>>> <zhenzhong.duan at oracle.com> wrote:
>>>>> Cpu doesn't get online automaticly after hotplug when we test guest cpu
>>>>> add/remove in xen env.
>>>>>
>>>>> I don't have an baremetal env to test this, but I think it's same.
>>>>>
>>>>> The rule is missed in systemd but exist in legacy udev.
>>>>
>>>> Udev is not a mechanism to establish an unconditional loop from the
>>>> kernel back to the kernel. Such rule makes no sense and we never
>>>> shipped that and will not ship it upstream now.
>>>>
>>>> If a device should be unconditionally change its state, the kernel
>>>> should just do that on its own, and not rely on userspace to do that.
>>>
>>>
>>> Kay,
>>>
>>> I’m curious.   Are you thinking of 40-redhat.rules in the RHEL6 udev as not being part of the legacy distribution?
>>>
>>> Should there be a rule that uses a systemd target to hot-add CPUs to provide the conditional aspect that’s needed?  Am I right in thinking that this is as simple as turning the old redhat rule into something like
>>>
>>> ACTION==“add” KERNEL==“cpu[0-9]*” TAG+=“systemd” ENV{SYSTEMD_WANTS}+=“cpuadd.service”
>>>
>>> And the corresponding service’s ExecStart is what actually puts the CPU on line?
>>>
>>> Sorry for the questions, I’m still trying to find the time to get to grips with systemd — that’s a poor excuse for something that’s been around for some considerable time I know, but be kind to me :)
>>
>> No, that is the same, just even more complicated. Establishing
>> unconditional loops from the kernel trough userspace back to the
>> kernel are wrong and pointless. If the CPU should always be onlined
>> with that event, please change the kernel to do that on its own, and
>> do not hook up userspace to do that.
> 
> Does that not depend on what cpuadd.service actually does? (and I'm
> guessing it should probably be cpuadd@$name.service" or something
> appropriate to identify the single CPU in question).
> 
> If there is some kind of conditional logic in the service (perhaps
> checking current system load before deciding if it's needed) then I
> presume this is something legitimate and valid?
> 
> It's just the fact that there is currently no logic at all involved
> currently that makes this pointless and something the kernel could do on
> it's own.

That's what I thought.  I have no idea what the policy for deciding
whether a cpu should be brought on line might be: it could be as simple
as limiting the maximum number of CPUs or it could be as complicated as
only allowing prime numbered CPUs on Wednesday(*).  The default
/lib/systemd/system/cpuadd*.service would implement the policy "if it's
there we want it" and someone needing something more complex can
override it with /etc/systemd/system/cpuadd*.service.

Col, forgive my ignorance, but cpuadd@$name.service seems to imply that
you'd have one file or symlink per CPU.  That's going to be unwieldy
when you have hundreds of CPUs isn't it?

jch

> 
> Col
> 
> 



(*) My employer is not alone in licensing by CPU so only allowing a
specified number of CPUs or only allowing CPUs with some specific
topographical relationship is not beyond the bounds of reason.