[tesla-dev] _PSD -> Power Processor Groups

[Li, Aubrey]

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