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
