Li, Aubrey wrote:
> 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.
>
The idle thread will keep track of how successful it is at entering
deeper sleep states.
> Is there any other policy/element to determine next idle state type?
>
These two "states" of a processor seem like the most important
inputs to deciding which future C-state to attempt to enter:
1) Time interval until next cyclic firing.
2) Which power PG the processor is in.
We suspect Solaris will be pretty good at predicting which C-state
it can successfully enter with the above data.
We discussed this briefly when Mark was here. Last successful
idle state did not seem like a good prediction of the future.
It will be interesting to see have accurate each algorithm is when
we run the experiments. :-)
Bill
> 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
>>>>
