On Mon, Apr 13, 2009 at 9:40 PM, Jürgen Keil <[email protected]> wrote: >> >> Frequency transition now occurs during the thread switching if the >> >> cmt_utilization >> >> of the power active domain think it's necessary. >> >> It's(event-mode) much more sensitive than before(poll-mode), even "kstat >> >> | grep >> >> current_clock_Hz" is possible to trigger a frequency transition. So, now, >> >> powertop >> >> is more reliable to report the cpu frequency utilization. >> > >> > The "P-states (frequencies)" statistic of powertop is showing >> > four entries (996, 1328, 1660 and 1992 MHz on a C2D T7200), >> > and I see either 100% at 996 Mhz, or 100% at 1992 MHz. >> > >> > That it doesn't use the 1328 and 1660 Mhz frequencies >> > is already reported as bug 6808377 "event based CPUPM >> > could leverage mid range speeds". >> >> Yeah, exactly by the current design. >> >> > >> > But why is it always reporting a frequency usage split for 996 >> > and 1992 MHz as 100% - 0% (or 0% - 100%) ? Somehow it >> > doesn't make sense that in event-mode (according to powertop) >> > the cpu is always running at the slowest (highest) speed during >> > the 5 second powertop sample interval. >> >> I attached a dtrace probe for your interest, which is exactly what powertop >> is currently using. >> I actually saw some mid value on the 16 logical cores system. > > It's a bug in powertop. The dtrace code that powertop is using > aggregates on a processorid_t (cpu) and an uint32_t (cpuspeed). > > But in function pt_cpufreq_dtrace_walk() the cpu speed is > read as uint64_t - this is working with bogus values for cpu > speed! > > Suggested fix: > > diff --git a/usr/src/cmd/powertop/common/cpufreq.c > b/usr/src/cmd/powertop/common/cpufreq.c > --- a/usr/src/cmd/powertop/common/cpufreq.c > +++ b/usr/src/cmd/powertop/common/cpufreq.c > @@ -431,7 +431,7 @@ pt_cpufreq_dtrace_walk(const dtrace_aggd > dtrace_recdesc_t *cpu_rec, *speed_rec; > cpu_power_info_t *cpu_pow; > int32_t cpu; > - uint64_t speed; > + uint32_t speed; > hrtime_t dt_state_time = 0; > int i; > > @@ -447,7 +447,7 @@ pt_cpufreq_dtrace_walk(const dtrace_aggd > /* LINTED - alignment */ > cpu = *(int32_t *)(data->dtada_data + cpu_rec->dtrd_offset); > /* LINTED - alignment */ > - speed = *(uint64_t *)(data->dtada_data + > + speed = *(uint32_t *)(data->dtada_data + > speed_rec->dtrd_offset); > > if (speed == 0) { > --
Thanks, I'll forward this patch to the tesla. But it's unrelated with 0% and 100% frequency residency. -Aubrey _______________________________________________ opensolaris-discuss mailing list [email protected]
