On Sat, Sep 5, 2009 at 11:40 PM, Aubrey Li<[email protected]> wrote: > On Sat, Sep 5, 2009 at 9:40 PM, Sebastien Roy<[email protected]> wrote: >> On Sat, 2009-09-05 at 16:31 +0800, Aubrey Li wrote: >>> On Sat, Sep 5, 2009 at 10:59 AM, Sebastien Roy<[email protected]> wrote: >>> > On Sat, 2009-09-05 at 10:38 +0800, Aubrey Li wrote: >>> > I wonder what changed. >>> >>> to put this simply, the default mode is event driving, which makes the >>> p-state >>> transition decision by several sampling points. It's more aggressive. >>> >>> "poll-mode" makes the transition decision by a tunable sampling period. The >>> period is 1s on your system (cpu-threshold 1s). It's more stable. >> >> Hmm, is it then possible that when event driven mode is used, powertop >> simply can't observe the lower p-states because of its probe effect? >> > > I'm not clear what powertop reports on your system. Assume that you are using > powertop V1.2. Did you see 100% highest p-state residency? > > The alternative way is checking the current clock by kstat > $ kstat -i 1 | grep current_clock_Hz > > You could check it from time to time (10s or longer maybe), the instance > option(-i) here helps to reduce the load effect. > > Need to mention, I upgraded my system(24 logical cores) to b122 just now and > tried powertop in event mode. I saw 100% lowest frequency residency on my > side. >
hmm..., I should watch powertop report longer. Actually, I occasionally saw 100% lowest frequency residency, sometimes ~90% pn and ~10% p0, and the worst case, 50% pn and 50% p0. Sometimes the sampling points are just idle so we saw 100% or 90% lowest p-state residency, but sometimes the sampling points flick to a load, so we saw higher P0 residency. This is sort of unacceptable. -Aubrey _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
