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

[Colin Guthrie]

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.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/