Messages in this thread | | | Date | Fri, 19 Feb 2016 10:49:11 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH 1/1] intel_pstate: Increase hold-off time before busyness is scaled |
| |
On Thu, Feb 18, 2016 at 01:09:26PM -0800, Doug Smythies wrote: > On 2106.02.18 Rafael J. Wysocki wrote: > On Thu, Feb 18, 2016 at 12:11 PM, Mel Gorman wrote: > >> > >> Signed-off-by: Mel Gorman <mgorman@techsingularity.net> > >> --- > >> drivers/cpufreq/intel_pstate.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > >> index cd83d477e32d..54250084174a 100644 > >> --- a/drivers/cpufreq/intel_pstate.c > >> +++ b/drivers/cpufreq/intel_pstate.c > >> @@ -999,7 +999,7 @@ static inline int32_t get_target_pstate_use_performance(struct cpudata *cpu) > >> sample_time = pid_params.sample_rate_ms * USEC_PER_MSEC; > >> duration_us = ktime_us_delta(cpu->sample.time, > >> cpu->last_sample_time); > >> - if (duration_us > sample_time * 3) { > >> + if (duration_us > sample_time * 12) { > >> sample_ratio = div_fp(int_tofp(sample_time), > >> int_tofp(duration_us)); > >> core_busy = mul_fp(core_busy, sample_ratio); > >> -- > > The immediately preceding comment needs to be changed also.
Yes, it does. Thanks.
> Note that with duration related scaling only coming in at such a high > ratio it might be worth saving the divide and just setting it to 0. >
That sounds reasonable. I've queued up a test based on this as well as tests with the linux-next branch from linux-pm to see what falls out.
> > I've been considering making a change like this, but I wasn't quite > > sure how much greater the multiplier should be, so I've queued this > > one up for 4.6. > > > That said please note that we're planning to make one significant > > change to intel_pstate in the 4.6 cycle that's very likely to affect > > your results. > > Rafael: > > I started to test Mel's change added to your 3 patch set version 10. > > I only have one data point so far, I selected the test I did from one of Mel's > better results (although there is no reason to expect my computer to have > best results for the same operating conditions): >
It's a reasonable expectation.
> Stock kernel 4.5-rc4 just for reference: > Linux s15 4.5.0-040500rc4-generic #201602141731 SMP Sun Feb 14 22:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > Command line used: iozone -s 401408 -r 32 -f bla.bla -i 0 > Output is in Kbytes/sec > > KB reclen write rewrite > 401408 32 1895293 3035291 > _________________________________________________________________ > > Kernel 4.5-rc4 + jrw 3 patch set version 10 (nominal 3X duration holdoff) > Linux s15 4.5.0-rc4-rjwv10 #167 SMP Mon Feb 15 14:23:10 PST 2016 x86_64 x86_64 x86_64 GNU/Linux > > Command line used: iozone -s 401408 -r 32 -f bla.bla -i 0 > Output is in Kbytes/sec > > KB reclen write rewrite > 401408 32 2010558 3086354 > 401408 32 1945126 3127472 > 401408 32 1944807 3110387 > 401408 32 1948620 3110002 > AVE 1962278 3108554 > > Performance mode, for comparison: > > KB reclen write rewrite > 401408 32 2870111 5023311 > 401408 32 2869642 5149213 > 401408 32 2792053 5100280 > 401408 32 2863887 5149229 > _________________________________________________________________ > > Kernel 4.5-rc4 + jrw 3 patch set version 10 + mg 12X duration hold-off > Linux s15 4.5.0-rc4-rjwv10-12 #169 SMP Thu Feb 18 08:15:33 PST 2016 x86_64 x86_64 x86_64 GNU/Linux > > Command line used: iozone -s 401408 -r 32 -f bla.bla -i 0 > Output is in Kbytes/sec > > KB reclen write rewrite > 401408 32 1989670 3100580 > 401408 32 2062291 3112463 > 401408 32 2107637 3233567 > 401408 32 2111772 3340610 > AVE 2067843 3196805 > Gain Verses 3X 5.4% 2.8% > _________________________________________________________________ > > Mel: Did you observe any downside conditions? >
Not so far but my expectation is that any downside would be power consumption related. At worst, I expect the patch to have little or not performance impact in cases where there are a lot of cores, a lot of migration and the CPU core is idle longer than the new hold-off period. For power-consumption, I'm relying entirely on the output of turbostat to tell me if there are problems which may or may not be sufficient.
-- Mel Gorman SUSE Labs
| |