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?

Bill


>> 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
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>   


Reply via email to