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.ha...@oracle.com> wrote: >>> >>> On 2 Sep 2014, at 06:55, Kay Sievers <k...@vrfy.org> wrote: >>> >>>> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan >>>> <zhenzhong.d...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel