From: Francisco Jerez <currojerez@riseup.net>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Eero Tamminen <eero.t.tamminen@intel.com>,
lenb@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org
Cc: mgorman@techsingularity.net, ggherdovich@suse.cz,
peterz@infradead.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpufreq: intel_pstate: Optimize IO boost in non HWP mode
Date: Wed, 05 Sep 2018 21:20:08 -0700 [thread overview]
Message-ID: <87in3j9s07.fsf@riseup.net> (raw)
In-Reply-To: <8c56f28c2cc11de37fa3517348559eb040894702.camel@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 4026 bytes --]
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> writes:
> [...]
>
>> > >
>> > > This patch causes a number of statistically significant
>> > > regressions
>> > > (with significance of 1%) on the two systems I've tested it
>> > > on. On
>> > > my
>> >
>> > Sure. These patches are targeted to Atom clients where some of
>> > these
>> > server like workload may have some minor regression on few watts
>> > TDP
>> > parts.
>>
>> Neither the 36% regression of fs-mark, the 21% regression of sqlite,
>> nor
>> the 10% regression of warsaw qualify as small. And most of the test
>> cases on the list of regressions aren't exclusively server-like, if
>> at
>> all. Warsaw, gtkperf, jxrendermark and lightsmark are all graphics
>> benchmarks -- Latency is as important if not more for interactive
>> workloads than it is for server workloads. In the case of a conflict
>> like the one we're dealing with right now between optimizing for
>> throughput (e.g. for the maximum number of requests per second) and
>> optimizing for latency (e.g. for the minimum request duration), you
>> are
>> more likely to be concerned about the former than about the latter in
>> a
>> server setup.
>
> Eero,
> Please add your test results here.
>
> No matter which algorithm you do, there will be variations. So you have
> to look at the platforms which you are targeting. For this platform
> number one item is use of less turbo and hope you know why?
Unfortunately the current controller uses turbo frequently on Atoms for
TDP-limited graphics workloads regardless of IOWAIT boosting. IOWAIT
boosting simply exacerbated the pre-existing energy efficiency problem.
> On this platform GFX patch caused this issue as it was submitted after
> io boost patchset. So rather that should be reverted first before
> optimizing anything.
>
>
>
>>
>> > But weighing against reduced TURBO usage (which is enough trigger)
>> > and
>> > improvement in tests done by Eero (which was primary complaint to
>> > us).
>> >
>> > It is trivial patch. Yes, the patch is not perfect and doesn't
>> > close
>> > doors for any improvements.
>> >
>>
>> It's sort of self-contained because it's awfully incomplete.Don't
>> agtr
>
>>
>> > I see your idea, but how to implement in acceptable way is a
>> > challenge.
>>
>> Main challenge was getting the code to work without regressions in
>> latency-sensitive workloads, which I did, because you told me that it
>> wasn't acceptable for it to cause any regressions on the Phoronix
>> daily-system-tracker, whether latency-bound or not.
> Yes, because your intention was to have a global change not a low power
> Atom specific,
>
My intention was to target low-power Atoms only since the first day we
discussed this problem. The cover letter of the series I sent and the
commit messages make this fairly clear.
>> What is left in
>> order to address Peter's concerns is for the most part plumbing,
>> that's
>> guaranteed not to have any functional impact on the heuristic. The
>> fact
>> that we don't expect it to change the performance of the system makes
>> it
>> substantially less time-consuming to validate than altering the
>> performance trade-offs of the heuristic dynamically in order to avoid
>> regressions (which is what has kept my systems busy most of the time
>> lately). Seems like my series, even in its current state without the
>> changes requested by Peter is closer to being ready for production
>> than
>> this patch is.
>
> Sorry, Not at all. We call such patches as experimental series.
The numbers speak otherwise.
> You caused 100% regression to idle power. There is no version 2 after
> that, even if you fixed locally even to look.
>
I did post a link to a v2 that fixed the idle power issue on the v1
thread, but I didn't intend to send it for review yet. I'll send it out
once I've fully taken into account Peter's feedback.
> Thanks,
> Srinivas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2018-09-06 4:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 17:28 [PATCH] cpufreq: intel_pstate: Optimize IO boost in non HWP mode Srinivas Pandruvada
2018-09-03 15:10 ` Eero Tamminen
2018-09-03 15:15 ` Srinivas Pandruvada
2018-09-04 6:53 ` Francisco Jerez
2018-09-04 17:50 ` Srinivas Pandruvada
2018-09-05 1:37 ` Francisco Jerez
2018-09-05 5:59 ` Srinivas Pandruvada
2018-09-06 4:20 ` Francisco Jerez [this message]
2018-09-11 11:21 ` Rafael J. Wysocki
2018-09-11 17:35 ` Francisco Jerez
2018-09-14 8:58 ` Rafael J. Wysocki
2018-09-15 6:34 ` Francisco Jerez
2018-09-17 9:07 ` Rafael J. Wysocki
2018-09-17 21:23 ` Francisco Jerez
2018-09-11 10:29 ` Rafael J. Wysocki
2018-09-11 10:28 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87in3j9s07.fsf@riseup.net \
--to=currojerez@riseup.net \
--cc=eero.t.tamminen@intel.com \
--cc=ggherdovich@suse.cz \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).