From: Juri Lelli <juri.lelli@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
tglx@linutronix.de, mingo@redhat.com, bp@suse.de,
lenb@kernel.org, rjw@rjwysocki.net, mgorman@techsingularity.net,
x86@kernel.org, linux-pm@vger.kernel.org,
viresh.kumar@linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC/RFT] [PATCH 02/10] cpufreq: intel_pstate: Conditional frequency invariant accounting
Date: Thu, 17 May 2018 17:04:18 +0200 [thread overview]
Message-ID: <20180517150418.GF22493@localhost.localdomain> (raw)
In-Reply-To: <20180517105907.GC22493@localhost.localdomain>
On 17/05/18 12:59, Juri Lelli wrote:
> On 16/05/18 18:31, Juri Lelli wrote:
> > On 16/05/18 17:47, Peter Zijlstra wrote:
> > > On Wed, May 16, 2018 at 05:19:25PM +0200, Juri Lelli wrote:
> > >
> > > > Anyway, FWIW I started testing this on a E5-2609 v3 and I'm not seeing
> > > > hackbench regressions so far (running with schedutil governor).
> > >
> > > https://en.wikipedia.org/wiki/Haswell_(microarchitecture)#Server_processors
> > >
> > > Lists the E5 2609 v3 as not having turbo at all, which is basically a
> > > best case scenario for this patch.
> > >
> > > As I wrote earlier today; when turbo exists, like say the 2699, then
> > > when we're busy we'll run at U=2.3/3.6 ~ .64, which might confuse
> > > things.
> >
> > Indeed. I was mostly trying to see if adding this to the tick might
> > introduce noticeable overhead.
>
> Blindly testing on an i5-5200U (2.2/2.7 GHz) gave the following
>
> # perf bench sched messaging --pipe --thread --group 2 --loop 20000
>
> count mean std min 50% 95% 99% max
> hostname kernel
> i5-5200U test_after 30.0 13.843433 0.590605 12.369 13.810 14.85635 15.08205 15.127
> test_before 30.0 13.571167 0.999798 12.228 13.302 15.57805 16.40029 16.690
>
> It might be interesting to see what happens when using a single CPU
> only?
>
> Also, I will look at how the util signals look when a single CPU is
> busy..
And this is showing where the problem is (as you were saying [1]):
https://gist.github.com/jlelli/f5438221186e5ed3660194e4f645fe93
Just look at the plots (and ignore setup).
First one (pid:4483) shows a single task busy running on a single CPU,
which seems to be able to sustain turbo for 5 sec. So task util reaches
~1024.
Second one (pid:4283) shows the same task, but running together with
other 3 tasks (each one pinned to a different CPU). In this case util
saturates at ~943, which is due to the fact that max freq is still
considered to be the turbo one. :/
[1] https://marc.info/?l=linux-kernel&m=152646464017810&w=2
next prev parent reply other threads:[~2018-05-17 15:04 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-16 4:49 [RFC/RFT] [PATCH 00/10] Intel_pstate: HWP Dynamic performance boost Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 01/10] x86,sched: Add support for frequency invariance Srinivas Pandruvada
2018-05-16 9:56 ` Peter Zijlstra
2018-05-16 4:49 ` [RFC/RFT] [PATCH 02/10] cpufreq: intel_pstate: Conditional frequency invariant accounting Srinivas Pandruvada
2018-05-16 7:16 ` Peter Zijlstra
2018-05-16 7:29 ` Peter Zijlstra
2018-05-16 9:07 ` Rafael J. Wysocki
2018-05-16 17:32 ` Srinivas Pandruvada
2018-05-16 15:19 ` Juri Lelli
2018-05-16 15:47 ` Peter Zijlstra
2018-05-16 16:31 ` Juri Lelli
2018-05-17 10:59 ` Juri Lelli
2018-05-17 15:04 ` Juri Lelli [this message]
2018-05-17 15:41 ` Srinivas Pandruvada
2018-05-17 16:16 ` Peter Zijlstra
2018-05-17 16:42 ` Srinivas Pandruvada
2018-05-17 16:56 ` Rafael J. Wysocki
2018-05-17 18:28 ` Peter Zijlstra
2018-05-18 7:36 ` Rafael J. Wysocki
2018-05-18 10:57 ` Patrick Bellasi
2018-05-18 11:29 ` Peter Zijlstra
2018-05-18 13:33 ` Patrick Bellasi
2018-05-30 16:57 ` Patrick Bellasi
2018-05-18 14:09 ` Valentin Schneider
2018-05-16 15:58 ` Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 03/10] cpufreq: intel_pstate: Utility functions to boost HWP performance limits Srinivas Pandruvada
2018-05-16 7:22 ` Peter Zijlstra
2018-05-16 9:15 ` Rafael J. Wysocki
2018-05-16 10:43 ` Peter Zijlstra
2018-05-16 15:39 ` Srinivas Pandruvada
2018-05-16 15:41 ` Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 04/10] cpufreq: intel_pstate: Add update_util_hook for HWP Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 05/10] cpufreq: intel_pstate: HWP boost performance on IO Wake Srinivas Pandruvada
2018-05-16 7:37 ` Peter Zijlstra
2018-05-16 17:55 ` Srinivas Pandruvada
2018-05-17 8:19 ` Peter Zijlstra
2018-05-16 9:45 ` Rafael J. Wysocki
2018-05-16 19:28 ` Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 06/10] cpufreq / sched: Add interface to get utilization values Srinivas Pandruvada
2018-05-16 6:40 ` Viresh Kumar
2018-05-16 22:25 ` Srinivas Pandruvada
2018-05-16 8:11 ` Peter Zijlstra
2018-05-16 22:40 ` Srinivas Pandruvada
2018-05-17 7:50 ` Peter Zijlstra
2018-05-16 4:49 ` [RFC/RFT] [PATCH 07/10] cpufreq: intel_pstate: HWP boost performance on busy task migrate Srinivas Pandruvada
2018-05-16 9:49 ` Rafael J. Wysocki
2018-05-16 20:59 ` Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 08/10] cpufreq: intel_pstate: Dyanmically update busy pct Srinivas Pandruvada
2018-05-16 7:43 ` Peter Zijlstra
2018-05-16 7:47 ` Peter Zijlstra
2018-05-16 4:49 ` [RFC/RFT] [PATCH 09/10] cpufreq: intel_pstate: New sysfs entry to control HWP boost Srinivas Pandruvada
2018-05-16 4:49 ` [RFC/RFT] [PATCH 10/10] cpufreq: intel_pstate: enable boost for SKX Srinivas Pandruvada
2018-05-16 7:49 ` Peter Zijlstra
2018-05-16 15:46 ` Srinivas Pandruvada
2018-05-16 15:54 ` Peter Zijlstra
2018-05-17 0:52 ` Srinivas Pandruvada
2018-05-16 6:49 ` [RFC/RFT] [PATCH 00/10] Intel_pstate: HWP Dynamic performance boost Juri Lelli
2018-05-16 15:43 ` Srinivas Pandruvada
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=20180517150418.GF22493@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=bp@suse.de \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.org \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.