Hi Mark,
Please refer to comments below.
Mark.Haywood at Sun.COM <mailto:Mark.Haywood at Sun.COM> wrote:
> Liu, Jiang wrote:
>> Hi Mark and Anup,
>> Currently I'm working on a project relative to CPU
> hotplug on x86 system. The new design is much more friendly to
> CPU hotplug than currently on in onnv tree, really appreciate
> your work. I still have several questions relative to CPU hotplug.
>> 1) Could you please help to turn on support for driver
> detach in cpudrv.c? CPU hotplug has dependency on that.
>>
>
> I'll look into it to see what's involved and get back to you.
>
>> 2) Seems cpupm subsystem still needs configuration item
> 'domain_cpu-devices="/cpus/c...@*"' in ppm.conf to catch all
> cpus at boot time. We are discussing some sort of device tree
> reorganization for x86 system, which may break current CPU
> domain support code in ppm driver. The sample device tree as below,
>> /devices/sysbus/processor at 0/cpu at 0
>> /devices/sysbus/processor at 0/cpu at 1
>> /devices/sysbus/processor at 1/cpu at 2
>> /devices/sysbus/processor at 1/cpu at 3
>> I think it's not ease to fit above device tree into
> current ppm driver on x86 system, any suggestion here?
>>
>
> Well, what you really want is something like:
> /devices/sysbus/proces...@*/c...@*
>
> but the ppm parsing code doesn't support that. I don't have any good
> suggestions at the moment other than to modify the ppm parsing code.
>
>> 3) Should line 876 and 896 in cpu_idle.c be removed? Seems it's not
>> used any more.
>>
>
> Yep. Thanks!
>
>> 4) Should we add reference count support in CPU domain
> data structure? For current implementation, all P/T/C domains
> will be freed if cpupm_free is called once for any cpu, which
> will make all cma_domain fields in cpupm_mach_state_t invalid.
> It may cause access violation, I think. It will also be needed
> to support CPU hotplug.
>>
>
> Yes, I think you are right. The domain code needs a bit more work. I'm
> not real happy with it anyway. I'll see what I can do to make it a
> little more robust.
>
>> 5) Seems current CPU domain relative code doesn't
> support CPU hot adding/removing, is that true?
>>
>
> That's true. We should really identify what we need to do to
> support it.
> I know that detach() is high on the list, but I think that filters
> down into being able to cleanup/disable domains. I'm not sure what
> else it means. If you know of anything let us know.
That would be great and hope we could cooperate on that.
>
> As an aside, I've been thinking that we might just want to do away
> with the CPU driver for x86 once PAD is available. I just don't know
> that I see a reason that anyone would prefer it over PAD. And doing
> away with the driver alleviates some problems (like the ppm stuff).
> Anyone have an
> opinion on this?
Yes, doing away with CPU driver may simplify the implementation.
One benefit to keep a driver for cpu pm is that a special driver optimized for
specific hardware could be provided for cpus. But this benefit is not so
attractive because no real demand currently.
Some thoughts for fun, image that one day memory device provides CPU P-state
alike power management capability, is it beneficial to keep the same device
driver model for CPU and memory "P-state" support?
Thanks!
>
> Thanks,
> Mark
>
>> Thanks!
>>
>>
>>> -----Original Message-----
>>> From: tesla-dev-bounces at opensolaris.org
>>> [mailto:tesla-dev-bounces at opensolaris.org] On Behalf Of Mark
>>> Haywood Sent: 2008?12?9? 10:14 To: tesla-dev at opensolaris.org
>>> Subject: [tesla-dev] CPUPM support in the kernel
>>>
>>> Anup and I have been working on moving the core CPUPM support from
>>> the CPU driver - into the kernel. Our goal is to make the CPU driver
>>> specific to polling CPU power management and not have PAD
>>> depend on the
>>> driver at all. That means moving a fair bit of the i86pc specific
>>> CPU power management support (ACPI parsing and caching, speedstep,
>>> pwrnow, cstate and tstate handling) into the kernel. This
>>> eliminates the need for callback mechanism into the CPU driver.
>>> Unfortunately,
>>> since acpica
>>> is a module, it does require callbacks for that. But those have been
>>> centralized into the existing uts/i86pc/os/acpi_stubs.c file.
>>>
>>> We've posted a webrev of our effort at:
>>>
>>> http://cr.opensolaris.org/~mhaywood/cpupm-move/
>>>
>>> We'd appreciate any comments.
>>>
>>> Thanks!
>>> Mark
>>>
>>> _______________________________________________
>>> tesla-dev mailing list
>>> tesla-dev at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
