Liu, Jiang wrote: > Hi Bill, > We faced the same issue when developing FIPE driver for > memory power saving. And we have adopted a hybrid algorithm to > handle this issue. The basic idea is to choose power saving state > according to time based statistics. Other than time based idle > percent calculation, we also track entrances to/exit from idle state > during a time period. If there are two many idle/busy switches during > a period, we will disable power-saving a sometime. > So as Bill has mentioned, such a hybrid algorithm may be > also suitable to deep C driver. > Thanks!
Since we changed to time based statistics, I think what Bill worried about is the time of sampling period is too long for the "ping pong" workload. The hybrid governor here means the hybrid statistics approach. Is this addressed in FIPE? The current c-state governor not only checks idle%, but entrances to/exit from idle state(thru idle interval), and average idle residency as well to throttle deep c-state if necessary. Thanks, -Aubrey > Bill Holler <> wrote: >> We currently do not allow the user to select a power/performance >> profile. This seems like something we eventually require for >> tunablity. >> >> The initial OpenSolaris could not introduce any performance >> regressions over a wide range of benchmarks. There is a huge >> opportunity for tuning for power if we are not constrained by 100% >> performance. >> I definitely saw during evaluation power improvements from c-state >> governor changes such as Aubrey's proposal. There are a number of >> thread scheduling improvements as well I would like to get back to. >> ;-) Having power/perf profiles or "knobs" would really make it easier >> to introduce better algorithms which work really well in specific >> situations with different power, performance, and response time >> requirements. >> >> Regards, >> Bill >> >> >> >> On 05/22/09 16:17, Bill Holler wrote: >>> Hi Aubrey, >>> >>> Time based sample periods were initially investigated, but they >>> performed poorly with "ping pong" type workloads such as >>> producer consumer etc. The problem was it took too long to >>> recognize a load change when the CPU had very short idle >>> and load periods. The current idle-rate based sampling shows >>> very little to no regression on benchmarks such as libmicro. >>> >>> How does the proposed change look in libmicro? >>> >>> We may need to use a hybrid governor which looks at both >>> idle rate and a fixed sample period. >>> >>> Thank you, >>> Bill >>> _______________________________________________ >>> tesla-dev mailing list >>> tesla-dev at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev >> >> _______________________________________________ >> tesla-dev mailing list >> tesla-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/tesla-dev > > Liu Jiang (Gerry) > OpenSolaris, OTC, SSG, Intel
