From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757887AbcIGP0W (ORCPT ); Wed, 7 Sep 2016 11:26:22 -0400 Received: from cmta20.telus.net ([209.171.16.93]:47554 "EHLO cmta20.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757871AbcIGP0R (ORCPT ); Wed, 7 Sep 2016 11:26:17 -0400 X-Authority-Analysis: v=2.2 cv=Jo8elIwC c=1 sm=1 tr=0 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=IkcTkHD0fZMA:10 a=suj81NHdXUfQpftGeI8A:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=4ztku6YoH9iJdXBZ:21 a=Ng5GYZJpqws4BHRg:21 a=QEXdDO2ut3YA:10 From: "Doug Smythies" To: "'Rafael J. Wysocki'" , "'Linux PM list'" Cc: "'Linux Kernel Mailing List'" , "'Srinivas Pandruvada'" , "'Peter Zijlstra'" , "'Viresh Kumar'" , "'Ingo Molnar'" , "'Vincent Guittot'" , "'Morten Rasmussen'" , "'Juri Lelli'" , "'Dietmar Eggemann'" , "'Steve Muckle'" References: <2730042.XLMy9dAKI1@vostro.rjw.lan> fzJYbhOgVcv8ifzJabBXDd In-Reply-To: fzJYbhOgVcv8ifzJabBXDd Subject: RE: [RFC/RFT][PATCH 2/4] cpufreq: intel_pstate: Change P-state selection algorithm for Core Date: Wed, 7 Sep 2016 08:26:05 -0700 Message-ID: <005401d2091c$2885fe50$7991faf0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdIFfoTZAZ6SjGpZQoy9UBxO5sMoxwDlfioA Content-Language: en-ca X-CMAE-Envelope: MS4wfNtgViP9xbAzbEjxzX9j+0l3DoS7iXpQJFa7jqdGDlJViFuXVCzV97T172TpJHGK9l8XPN0y0qULjGf7CzkTcnurIghlSP12Tnb7PiJCPM541vInvahj wWyd3RCL03JmCHLabB/j59nvCJVdokgZWAUVfZuO1bdpo/1mA2EkklmSATUyDNdiY8sYAiFhj5VEUw7PPoepgcIGKw6V1q+mCB/osfTqxNSWZBbh38m17/Ej VhA2pB299z0H1sxghw+iU2YL82IgO7bd/YCzP5cjXMAVz+g2B+f/Fm9tO5xjdnR08gr0r9U5zzw4AzxjFnOc2uPwvPOG/96pgASEGCBYQvzPassHqcSmV5QM g13S4zz5RS9KbpK2UymEULP9gqwulz/qOXNSFD7vLHpFJp3aZh8AUZAzEdNfTCTA7efIPdfQtbUtZSViC7EQ0Tre/ebAxAHTGpR+qh2Gk6sAqLAsA7gAjQdq NRtswFnhJomEid1C2RVpZbUGW+jAivL8jMbXqud2sYZ85A7TzbaOwQ+qf2HTX4zx0BJNG+ZwipxqPIhK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016.09.02 18:02 Rafael J. Wysocki wrote: ...[cut]... > This includes an IIR filter on top of the load-based P-state selection, > but the filter is applied to the non-boosted case only (otherwise it > defeats the point of the boost) and I used a slightly different raw gain > value. The different gain value, 12.5% instead 10%, does come at a cost of some energy. Although we are finding inconsistencies in the test results. (I estimated about 2.2% energy cost, for my 20% SpecPower simulator test, and scaling off of a simple graph I did of energy vs gain with the previous version). ...[cut]... > + intel_pstate_get_min_max(cpu, &min_perf, &max_perf); > + target = clamp_val(target, int_tofp(min_perf), int_tofp(max_perf)); > + sample->target = fp_toint(target + (1 << (FRAC_BITS-1))); > + return sample->target; > +} > + In my earlier proposed versions, it was very much on purpose that it was keeping the pseudo floating point filtered target. Excerpt: + cpu->sample.target = div_u64((int_tofp(100) - scaled_gain) * + cpu->sample.target + scaled_gain * + unfiltered_target, int_tofp(100)); + /* + * Clamp the filtered value. + */ + intel_pstate_get_min_max(cpu, &min_perf, &max_perf); + if (cpu->sample.target < int_tofp(min_perf)) + cpu->sample.target = int_tofp(min_perf); + if (cpu->sample.target > int_tofp(max_perf)) + cpu->sample.target = int_tofp(max_perf); + + return fp_toint(cpu->sample.target + (1 << (FRAC_BITS-1))); Why? To prevent a lock up scenario where, depending on the processor and the gain settings, the target pstate would never kick over to the next value. i.e. if it only increased 1/3 of a pstate per iteration as the filter approached its steady state value. While this condition did occur in my older proposed implementations, with my processor it doesn't seem to with this implementation. I didn't theoretically check other processors. Another side effect of this change is effectively a further increase in the gain setting, and thus more energy being given back. This was determined by looking at step function load response times, as opposed to math analysis. (I can make pretty graphs if you want.) The purpose of this e-mail just to make us aware of the tradeoffs, not to imply it should change. ... Doug