Hi Bill,
Thanks for suggestion! Please refer to comments below!
Bill.Holler at Sun.COM <mailto:Bill.Holler at Sun.COM> wrote:
> Hi,
>
> Should idle-exit-ts be removed from this interface.
> The last-idle-time and last-busy-time fields provide the same info.
There's redundancy among, "idle-enter-ts", "idle-exit-ts", "last-idle-time"
and "last-busy-time". The basic idea here is provide convenience to
property comsumers, no matter which property it needs, it could directly
query it instead of computing it from another two properties.
>
> 4.2.11 should be removed? This spec describes this interface,
> but the kernel is free to set these properties any way it chooses.
I think it would be better to keep this interface for modules.
In new proposal the property data structure is transparent to other
modules, so .other modules need it to set properties.
For kernel itself, it may go thorough shortcuts instead of calling this
interface to set properties to pursue performance.
>
> I am not wild about adding all of this property overhead.
> Did we decide the kernel would not call the idle callbacks when
> it thinks a CPU will not be idle very long or the system is very
> busy?
Very good suggestion to avoid overhead.
When we integrate with cpupm-gate, it would be great to support such
an optimization to avoid calling callbacks if CPU is predicted to sleep
a very short time. In current implementation, we have no knowledge
about predicted sleep time so have no chance for such an optimization.
I will add some statement into PSARC onepager to talk about the possible
optimization.
>
> Regards,
> Bill
>
>
> On 02/21/09 18:44, Liu, Jiang wrote:
>> Hi buddies,
>> I have made some changes/enhancements to CPU idle notification PSARC
>> onepager according to feedbacks from PSARC review. Please help to
>> review it and I'll send it to Randy after passing community review.
>>
>> 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.
>> Among which, accessing CPU idle properties through interface is a
>> big
>> change to previous version. By adopting such a mechanism, it could
>> give us following benefits: 1) Easier to handle compatibility
>> issues. 2) Generating CPU idle property on demand. If there's no
>> consumer for a property, it won't be generated.
>> On the other hand, CPU idle notification callbacks are performance
>> sensitive, so the new interfaces have been designed to minimize the
>> performance penalty.
>>
>> If it's possible, please provide your feedback ASAP because the
>> PSARC
>> review deadline is February 25th.
>> Thanks!
>>
>> Liu Jiang (Gerry)
>> Senior Software Engineer
>> OpenSolaris, OTC, SSG, Intel
>> Tel: (8610)82171643
>> iNet: 8-758-1643
>> Location: Raycom 9W013
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/tesla-dev/attachments/20090224/02eb58cf/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: onepager_v4_v6.diff
Type: application/octet-stream
Size: 6900 bytes
Desc: onepager_v4_v6.diff
URL:
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20090224/02eb58cf/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: onepager_v5_v6.diff
Type: application/octet-stream
Size: 429 bytes
Desc: onepager_v5_v6.diff
URL:
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20090224/02eb58cf/attachment-0001.obj>
