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. 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? 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 >> >>
