Eric Saxe wrote:
> Mark Haywood wrote:
>
>> Mark Haywood wrote:
>>
>>
>>> It was recently pointed out to me that the CPU driver is printing (a
>>> very poorly worded) message to the system error log every time it
>>> receives a _PPC change notification. For those who don't know what a
>>> _PPC is, it's an ACPI object that informs the OS which of the defined
>>> P-states are accessible. That is, it's like a governor on which P-states
>>> the OS should use. It's frequently used by the platform to force the
>>> processors down to a lower frequency as a thermal control mechanism.
>>>
>>> The _PPC can change dynamically and when it does it is possible for the
>>> OS to find out about the change by registering a change notification
>>> handler. The CPU driver does register a handler and as I mentioned above
>>> is printing an error message to the system error log it is invoked.
>>> Printing the message to the system error log was apparently a mistake.
>>> Some platforms are changing the _PPC values much more often that I expected.
>>>
>>> I've already filed:
>>>
>>> 6636222 "NOTICE: cpudrv_pm_set_topspeed: instance 0: has new max power
>>> of 2000 MHz" needs to go
>>>
>>> to remove the message. But was thinking that we might want to add
>>> another cpu_info kstat to track the current maximum permissible
>>> frequency for the processor. It would have to be an x86 only kstat
>>> probably tracked in the cpu_t structure in a similar fashion as
>>> cpu_curr_clock. I was wondering if anyone had an opinion on the
>>> usefulness of this data as a cpu_info kstat addition?
>>>
>>>
>> How about a DTrace proble instead of or in addition to the kstat?
>>
>>
>
> I wouldn't expect the maximum speed of the processor to change very
> often, so for this kind of a statistic a kstat makes pretty good sense
> to me. Is my assumption correct? Is this information already represented
> though in the supported_frequencies_Hz kstat (by virtue of the largest
> value?)
>
No, I don't believe it would change that often. I think it would be rare
for it to change more than a few times in a minute (and even that
frequently would probably be unusual). It is not currently represented
in the supported_frequencies_Hz kstat. That kstat displays all P-state
frequencies supported by the platform and I don't think that we should
be modifying that value due to _PPC change notifications (I think it
could cause confusion). If we're going to present it as a kstat, then I
think it would be better as a new kstat. Something like
current_frequency_max_limit_Hz. Sort of wordy. no?
> Thanks,
> -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
>
