[0/2] Add support for frequency invariance for (some) x86

Message

Giovanni Gherdovich Sept. 9, 2019, 2:42 a.m. UTC

This is a resend with of Peter Zijlstra's patch to support frequency
scale-invariance on x86 from May 2018 [see 1]. I've added some modifications
and included performance test results. If Peter doesn't mind, I'm slapping my
name on it :)

The changes from Peter's original implementation are:

1) normalizing against the 4-cores turbo level instead or 1-core turbo
2) removing the run-time search for when the above value isn't found in the
   various Intel MSRs -- the base frequency value is taken in that case.

The section "4. KNOWN LIMITATIONS" in the first patch commit message addresses
the reason why this approach was dropped back in 2018, and explains that the
performance gains outweight that issue.

The second patch from Srinivas is taken verbatim from the May 2018 submission
as it still applies.

I apologies for the length of patch #1 commit message; I've made a table of
contents with summaries of each section that should make easier to skim
through the content.

This submission incorporates the feedback and requests for additional tests
received during the presentation made at OSPM 2019 in Pisa three months ago.

[1] https://lore.kernel.org/lkml/[e-mail]/

Giovanni Gherdovich (1):
  x86,sched: Add support for frequency invariance

Srinivas Pandruvada (1):
  cpufreq: intel_pstate: Conditional frequency invariant accounting

 arch/x86/include/asm/topology.h |  29 +++++++
 arch/x86/kernel/smpboot.c       | 180 +++++++++++++++++++++++++++++++++++++++-
 drivers/cpufreq/intel_pstate.c  |   5 ++
 kernel/sched/core.c             |   1 +
 kernel/sched/sched.h            |   7 ++
 5 files changed, 221 insertions(+), 1 deletion(-)

Comments

Peter Zijlstra Sept. 24, 2019, 4:01 p.m. UTC | #1

On Mon, Sep 09, 2019 at 04:42:14AM +0200, Giovanni Gherdovich wrote:
> This is a resend with of Peter Zijlstra's patch to support frequency
> scale-invariance on x86 from May 2018 [see 1]. I've added some modifications
> and included performance test results. If Peter doesn't mind, I'm slapping my
> name on it :)

That is fine; all I did was write some code, you did the hard part and
made it 'work' :-)