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? > 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. 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 >
