Hi Randy, Garrent and Artem,
I have made some changes/enhancements to CPU idle notification PSARC
onepager according to kindly feedbacks from PSARC/Tesla review. Could you please
help to review it again? The attachments is the latest PSARC onepager and a
diff file
with previous version. The main changes include:
1) Add more comments to function parameters and return value.
2) Provide a suite of interfaces to access CPU idle properties instead
of directly accessing data structure fields in previous version.
3) Add constraints to call some interfaces.
Thanks for your kindly help!
Liu Jiang (Gerry)
OpenSolaris, OTC, SSG, Intel
Garrett D'Amore <> wrote:
> Liu, Jiang wrote:
>> Hi Garrent,
>>
>> Garrett D'Amore <> wrote:
>>
>>> Raj, Ashok wrote:
>>>
>>>>>> Predominantly, the issue to external devices is only idle, so
>>>>>> that they can take other actions to reduce power. Part of the
>>>>>> assumption here is that idle can absorb the extra latency
>>>>>> required by the callback and will reduce the impact to
>>>>>> performance. Considering that C/T/P-states will likely occur
>>>>>> very frequently, having additional notifications could
>>>>>> circumvent the value of those state transitions.
>>>>>>
>>>>>>
>>>>>>
>>>> Randy is right. Our initial target is just focused on memory power
>>>> management. This structure was a lot smaller when we started :-)
>>>> the other hints were added assuming there might be different
>>>> things we could do if we know more information.. say when next
>>>> timeout etc once we have tickless implementation etc. so we can
>>>> choose different state of power save for memory or other
>>>> subsystems.
>>>>
>>>>
>>>>
>>>>>> Evolution of PAD (Power Aware Dispatcher) may change some of
>>>>>> these considerations, but for now this is the most we want to
>>>>>> open the door.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Fair enough. But, IMO, all the more reason to avoid hard coding a
>>>>> structure and instead use property name/value pairs if at all
>>>>> possible. It sounds like there is potential for significant
>>>>> evolution here in the future.
>>>>>
>>>>>
>>>>>
>>>> Thanks Garrett. So you mean how we pass things like
>>>> ddi_set_prop_valu?? Etc? is there an example you can point to us
>>>> where a similar callback is structured in a form of name/value
>>>> pairs as you suggest.
>>>>
>>>> Seems like a good approach, just point us in the right direction.
>>>>
>>>> As you pointed out the version etc were just for consideration in
>>>> case we add new/remove old we could keep compatibility.. (but I
>>>> agree it's a weak approach, generally things would break and you
>>>> need to support legacy...)
>>>>
>>>>
>>> So, I wasn't requesting anything *specifically* tied to
>>> ddi_setprop, etc,
>>>
>>> A good example of what I'm talking about is how the SCSI
>>> capabilities are managed (scsi_ifgetcap()) -- you pass a numeric
>>> "name", and get back the value. You can do this in a read-write
>>> fashion too. For example, look at how SDcard uses "properties": in
>>> usr/src/uts/common/sys/sdcard/sda.h there are the sda_prop_t, and
>>> the associated setprop and getprop routines in the sda_ops
>>> structure.
>>>
>>>
>>
>> Excellent suggestion to expose data through interface instead of a
>> single data structure. By providing a suite of interface to query
>> value of properties, it would give us following benefits,
>> 1) Easier to deal with compatibility issues.
>> 2) Generate data on demand. CPU idle notification framework doesn't
>> need
>> to generate data for a property if no client requests for it.
>> On the other hand, CPU idle notification framework is performance
>> sensitive and it will give us some performance benefit by directly
>> access data fields in a structure. So we may keep on evolving on
>> this direction and make decision based on
>> more performance data.
>> Should I update the PSARC onepager to integrate this interface?
>> Thanks!
>>
>
> If you're going to change the interface, then please provide an update
> to the PSARC case materials.
>
> If there are compelling performance or consistency reasons where a
> single structure works better, that's fine. (But if the values don't
> need to be addressed atomically, and the cost to retrieve them
> separately is not prohibitive, then it may be better to go this
> route.)
>
> --Garrett
>
>>
>>
>>> -- Garrett
>>>
>>>> Cheers,
>>>> ashok
>>>>
>>
>> Liu Jiang (Gerry)
>> OpenSolaris, OTC, SSG, Intel
Liu Jiang (Gerry)
OpenSolaris, OTC, SSG, Intel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: onepager_v6.txt
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090226/bc149708/attachment.txt>
