Liu, Jiang wrote: > 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? > I assume the VM sub system might be able to leverage the CPUPM related feature in the kernel similar to PAD and may not require it in driver. But, I don't know about suspend/resume case.
Thanks Anup > 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 >>>> > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
