Eric Saxe 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. > - Currently Solaris only supports C0, C1 states, so this can be >hard-coded to start. > - 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). > - 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. > - Amount of time spent in each P-state can be meausured by a >DTrace probe which fires > when system changes CPU speed. > > Similar to above information, was curious about T-State information. The current cpu throttled percentage and the supported throttled states being exported through cpu_info kstats. Measuring amount of time spent in each T-state. I dont know how important it is, but just thought of asking the alias.
Thanks Anup > - Event information (interrupts) > - Can use existing DTrace probes that report on interrupt >activity (used by intrstat(1m) implementation). > - 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). > - Battery information > - Looking to plug into battery related kstats > >I've added the necessary DTrace probes...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 > > > >_______________________________________________ >tesla-dev mailing list >tesla-dev at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/tesla-dev > >
