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 > ====================== > 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
