Re: [PATCH v3 0/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate
On Tuesday, April 19, 2016 03:27:59 PM Akshay Adiga wrote: > The frequency transition latency from pmin to pmax is observed to be in few > millisecond granurality. And it usually happens to take a performance penalty > during sudden frequency rampup requests. > > This patch set solves this problem by using a chip-level entity called "global > pstates". Global pstate manages elements across other dependent core chiplets. > Typically, the element that needs to be managed is the voltage setting. > So by holding global pstates higher than local pstate for some amount of time > ( ~5 seconds) the subsequent rampups could be made faster. > > (1/2) patch removes the flag from cpufreq_policy->driver_data, so that it can > be used for tracking global pstates. > > (2/2) patch adds code for global pstate management. > - The iozone results with this patchset, shows improvements in almost all > cases. > - YCSB workload on redis with various target operations per second shows > better MaxLatency with this patch. > > Changes from v1: > - Fixed coding style > - Added a routine to reset global_pstate_info instead of hacky memset > - Handled case where cpufreq_table_validate_and_show() fails > - changed int queue_gpstate_timer() to void queue_gpstate_timer() > > Changes from v2: > - dropped the unreated change. > > Akshay Adiga (1): > cpufreq: powernv: Ramp-down global pstate slower than local-pstate > > Shilpasri G Bhat (1): > cpufreq: powernv: Remove flag use-case of policy->driver_data > > drivers/cpufreq/powernv-cpufreq.c | 269 > -- > 1 file changed, 256 insertions(+), 13 deletions(-) Both [1-2/2] applied, thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate
The frequency transition latency from pmin to pmax is observed to be in few millisecond granurality. And it usually happens to take a performance penalty during sudden frequency rampup requests. This patch set solves this problem by using a chip-level entity called "global pstates". Global pstate manages elements across other dependent core chiplets. Typically, the element that needs to be managed is the voltage setting. So by holding global pstates higher than local pstate for some amount of time ( ~5 seconds) the subsequent rampups could be made faster. (1/2) patch removes the flag from cpufreq_policy->driver_data, so that it can be used for tracking global pstates. (2/2) patch adds code for global pstate management. - The iozone results with this patchset, shows improvements in almost all cases. - YCSB workload on redis with various target operations per second shows better MaxLatency with this patch. Changes from v1: - Fixed coding style - Added a routine to reset global_pstate_info instead of hacky memset - Handled case where cpufreq_table_validate_and_show() fails - changed int queue_gpstate_timer() to void queue_gpstate_timer() Changes from v2: - dropped the unreated change. Akshay Adiga (1): cpufreq: powernv: Ramp-down global pstate slower than local-pstate Shilpasri G Bhat (1): cpufreq: powernv: Remove flag use-case of policy->driver_data drivers/cpufreq/powernv-cpufreq.c | 269 -- 1 file changed, 256 insertions(+), 13 deletions(-) -- 2.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
