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

John Haxby john.haxby at oracle.com
Tue Sep 2 08:30:03 PDT 2014


On 02/09/14 16:23, Kay Sievers wrote:
> On Tue, Sep 2, 2014 at 5:11 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>
>> John Haxby wrote on 02/09/14 10:31:
>>> 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?
>>
>> Not quite. systemd units with an @ in them are a bit special. You have
>> one unit file on disk (cpuadd at .service) and you can instantiate
>> instances of them via cpuadd at xxx.service where the value xxx is
>> available inside the unit and can be passed to scripts or binaries in
>> the ExecStart lines via the %i and %I modifiers.
>>
>> In this case you wouldn't ever enable them individually via explicit
>> symlinks (which is valid in some use cases) but udev would defer to
>> systemd to start the instance as needed. This is very similar to how the
>> built in systemd-rfkill at .service works. See
>> /usr/lib/systemd/system/systemd-rfkill at .service. It's instantiated as
>> systemd-rfkill at rfkill1.service for example.
>>
>>
>> It's basically the way to pass in the the CPU number or name to the
>> service so you can implement that mission critical "only allowing prime
>> numbered CPUs on Wednesday" policy ;)
> 
> Nice description. :)
> 
> But just in case someone thinks of any per-CPU onlining policy
> machinery now: We will not ship anything in that area in systemd/udev
> upstream. This stuff just belongs into the kernel, like it works for
> any other device.
> 

Do you mean that the kernel should not be generating udev events for cpu
hotplug?   Or that there is some other mechanism that the kernel should
be using to allow cpu hotplug policy to be decided by userland?


> Kay
> 



More information about the systemd-devel mailing list