Bill Holler wrote:
> Mark Haywood wrote:
>> Eric Saxe wrote:
>>  
>>> Mark Haywood wrote:
>>>    
>>>> Li, Aubrey wrote:
>>>>      
>>>>> I guess Eric means P-state and C-state.
>>>>> If so, _PSD describes P-State Dependency and _CSD describes C-state
>>>>> Dependency.
>>>>>               
>>>> Ah. Sorry. I'm familiar with the _CSD (and of course the _PSD), but 
>>>> didn't recognize what Eric was referring to. So, I assume that 
>>>> means _PSD defines the CPUs that share frequency change and C-state 
>>>> dependency defines the CPUs that share a voltage change?         
>>> Right, this is what I'm wondering as well (and I didn't know that 
>>> _CSD and _PSD described those two domains...is that really so?).
>>> We can have the dispatcher consider thread placement across both 
>>> levels if that makes sense.
>>>     
>>
>> The _PSD domains define the CPUs that share P-state dependencies. 
>> P-states are really a combination of frequency and voltage scaling.
>>
>> The _CSD domains define the CPUs that share C-state dependencies. Do 
>> C-states really just equate to voltage scaling? I don't know. Aubrey 
>> or Bill might know.
>>   
>
> Are _CSD/c-state domains "flat", or can these be in a tree?
> For example if there is a 4-core chip with two shared caches?
>
> I am having a hard time envisioning how the PAD will place
> threads across both _PSD and _CSD defined domains.
> Would the PAD prefer high p-state domains, and then
> lower p-state domains, and then lower c-state domains last?

My guess is that the _CSD and _PSD domains will be identical. I think 
Aubrey will have a better idea.
>
>
>> There are T-states (throttling) too. And they have domains defined by 
>> _TSD objects. I don't know if the dispatcher needs to know anything 
>> about them. Our only planned support for T-states is to allow for 
>> throttling in response to _TPC change notifications.
>>   
>
> Does software need to do the t-state throttling, or will
> hardware do this for us?  The _TPC change notifications
> could be useful for c-state domain selection assuming c-states
> are better than t-states for cooling.

The OSPM needs to handle the _TPC change notification and then write a 
value to a register that tells the CPU to throttle. I could see where 
this information might be useful in scheduling selection.

>
> Bill
>
>> Regardless, yes I think that the CPU Power Manager needs to abstract 
>> this info and make it available to the dispatcher to use.
>>
>>  
>>> -Eric
>>>     
>>
>> _______________________________________________
>> tesla-dev mailing list
>> tesla-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>>   
>


Reply via email to