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. >
That is similar to the CPU idle algorithm: 1) Idle percentage 2) Idle length long enough to enter deeper c-state 3) In addition we also track how long the CPU is "busy". If the CPU will not be busy long enough to amortize the cost of Deeper C-state wakeup-latency, then the CPU will not go into deeper C-state. This is the check missing from Aubrey's proposal. The check helps improve performance dramatically on latency-sensitive workloads that wake up for short periods of time. This check may be the one hurting SPECPower. :-( Regards, Bill > So as Bill has mentioned, such a hybrid algorithm may be > also suitable to deep C driver. > Thanks! > > 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 >
