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?) Thanks, -Eric > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
