Hi Mark,
When CPU hotplug is enabled, there are several scenarios which may
cause some CPUs in a domain are in working state and others in the same domain
are in stopped state. Here stopped state means that CPU doesn't run any OS
code, it has the same meaning with powered off, halted on x86 system. Possible
scenarios including,
1) At boot time, some CPUs will be kept in stopped state due to
"boot_ncpus" boot option's limitation.
2) Administrator issues cfgadm utility to put some logical CPUs into
stopped state.
3) FMA engine/agent puts some logical CPUs in question into stopped
state.
I don't know what's the cpupm's perspective to handle such a case with
some CPUs in a domain in stopped state.
From CPU hotplug's perspective, CPU should be put into lowest power
state possible before entering stopped state to be power friendly. Until now, I
haven't found any way to achieve this goal. As we know, ACPI supports three
types of domain coordination methods. Among those, SW_ANY is the easiest one to
deal with, HW_ALL is a little harder, SW_ALL is the hardest one because CPU in
stopped state doesn't run OS code. I have no idea on how to support SW_ALL, any
thoughts to break this cage?
Thanks!
Mark.Haywood at Sun.COM <mailto:Mark.Haywood at Sun.COM> wrote:
> Hi Gerry,
>
> Does it seem reasonable to enforce the requirement that all CPUs in a
> domain need to be power manageable in order to manage any of
> the CPUs in
> that domain? I don't know much about what you are planning to do with
> hotplug. Is it possible that one CPU in a domain will detach and
> others in the domain will be left attached?
>
> Thanks,
> Mark
>
> 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.
>> 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?
>> 3) Should line 876 and 896 in cpu_idle.c be removed? Seems it's not
>> used any more. 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.
>> 5) Seems current CPU domain relative code doesn't
> support CPU hot adding/removing, is that true?
>> 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
