On Saturday, October 27, 2007 11:06 PM, Mark.Haywood at Sun.COM wrote: > Li, Aubrey wrote: >> On Saturday, October 27, 2007 8:01 AM, > tesla-dev-bounces at opensolaris.org >> wrote: >> >>> The existing powertop implementation makes heavy use of /proc >>> under Linux. >>> For the necessary interfaces, here's what I'm thinking: >>> >>> - C-state information >>> - Number of C-states, and amount of time system is spending >>> in each one >>> - Number of C-states can eventually be exported through a >>> kstat. >> >> Where do you plan to add a kstat if there is no C-state driver? >> >>> - Currently Solaris only supports C0, C1 states, so this can >>> be hard-coded to start. >> >> Sounds fine for now. >> >>> - Amount of time spent in each C-state can be measured by a >>> DTrace probe which fires during C-state transistions (around >>> mwait, halt instruction invocations). >> >> Good enough. >> >>> - P-state information >>> - Number of P-states, their frequencies, and amount of time >>> system is spending in each one. >> >>> - Number of P-states, frequencies, and current state already >>> exported through cpu_info kstats. >> >> Here, on my side, stepping is 4, but supported frequencies have only >> 3. 4 is read from CPUID, 3 is read from ACPI. And 3 is what we need, >> Is it necessary to add a new member of cpu_info?
> > Why wouldn't we just parse supported frequencies? > > npstates = number of ':' + 1 > OK, parsing the supported frequencies is fine. >> ====================== >> module: cpu_info instance: 0 >> name: cpu_info0 class: misc ----snip---- >> stepping 4 >> supported_frequencies_Hz > 2000000000:2333000000:2667000000 >> ----snip---- >> ====================== >> >>> - Amount of time spent in each P-state can be meausured by a >>> DTrace probe which fires when system changes CPU speed. >>> - Event information (interrupts) >> >> Good enough. >> >>> - Can use existing DTrace probes that report on interrupt >>> activity (used by intrstat(1m) implementation). >> >> Intrstat just reports device interrupt activity, not enough, I think. >> We need to figure out which process is using this device,right? >> >>> - Event information (timer / callout activity) >>> - Can use existing callout related DTrace probes to report on >>> who's waking up and why (kernel and user activity). >> >> I'm looking at this now. Is it already done? >> >>> - Battery information >>> - Looking to plug into battery related kstats >> >> No machine avaiable for me to test now, :( >> >>> I've added the necessary DTrace probes... >> You are so quick, after 3 days of SUN Tech days China, the main >> function of powertop are almostly ready, ;-). >> Did you commit into PowerTop repo? >> >>> so i'm going to work on >>> extracting and formatting the needed data from the kernel >>> via libdtrace, and libkstat. I've taken a pass through powertop.c >>> and prepped the code for the Solaris changes (removing the Linux >>> specific portions). Once we get this prototyped, we should look at >>> how all this can be done so that we have the Linux and Solaris >>> specific code exists in an OS specific layer, with the common >>> code being >>> common to both. That way, all this can live in a common >>> source base. >>> >>> -Eric >>> >> Good idea, I think linux staff should be willing to accept such an >> OS specific layer patch. >> >> Thanks, >> -Aubrey >> _______________________________________________ >> tesla-dev mailing list >> tesla-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
