tesla-dev-bounces at opensolaris.org wrote: > Mark Haywood wrote: >> Eric Saxe wrote: >> >>> Hi Mark, Anup, >>> >>> I'm still working on the capturing what we had talked about last >>> week into the Power Aware Dispatcher design doc draft (still >>> working on it). >>> >>> With respect to the prototype, I'm interested in interfacing with >>> the CPU PM driver to get the information necessary to construct the >>> power processor groups....so that I can experiment with the >>> dispatcher policies. In thinking about this, and thinking back to >>> last week, the platform independent CPU "power manager", would >>> interface with the CPU PM driver, to enumerate the power manageable >>> CPU resources, and the associated abstracted states. >>> >>> I'm wondering if you think it makes sense for the CPU power manager >>> to export the interfaces to the Processor Grouping Framework. >>> Please see the attached figure... >>> >> >> Yes, I think it makes sense. I'd expect that such an interface might >> be a common PM policy engine interface and I guess in this case the >> the CPU power manager is part of the PM policy engine? Sarito might >> be able to provide some thoughts on whether this is what he'd >> envisioned. >> >> For prototyping purposes, it should be easy create a CPU "power >> manager" entity, have it get the processor group information from >> the CPU driver and present the information in some fashion to the >> PGF. >> > > C-state code would likely query the Processor Group information > every time a processor goes idle and its next cyclic is far enough in > the future to go to a deeper C-state. The C-state code needs a fast > interface such as accessing the pg data directly?
I guess wether processor go into idle or not depends on PG information. But the deeper c-state type still be determined by the last idle residency. Is there any other policy/element to determine next idle state type? Thanks, -Aubrey > > >>> The idea is for the Processor Grouping Framework to query the CPU >>> Power Manager for the CPU's power grouping information, and the CPU >>> power manager in turn would get this from the platform dependent CPU >>> PM driver, which would get it from ACPI, or the sun4v MD, etc. >>> >> >> This makes sense to me, but I'm not comfortable with how sun4v might >> do this. I want to make sure that someone more familiar with sun4v >> is good with this. >> >>> Have a nice weekend... >>> -Eric
