cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: cpufreq@vger.kernel.org
Cc: arjan@linux.intel.com, Len Brown <lenb@kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Michael Galbraith <mgalbraith@suse.de>
Subject: Disable cpufreq on modern X86 processors
Date: Tue, 24 Jul 2012 15:15:14 +0200	[thread overview]
Message-ID: <201207241515.15324.trenn@suse.de> (raw)

Hi,

I recently got pointed to performance losses measured
with and without cpufreq enabled when people worked on
scheduler tunables/improvements.

Depending on whether processes are bound to cores, tunables
inside the cpufreq subsystem, etc. there can be rather big
differences.

While there have been improvements (for example do not poll
that often if constantly running at highest frequency and
others), dynamic cpufreq adjusting as it currently is
implemented via ondemand/conservative governors always
will cost performance.

Arjan mentioned quite some time ago, that for modern X86
processors it does not make much sense to control the
frequency of the CPU via OS, because idle states are
much more efficient and should get entered asap.

Especially on bigger X86 systems with dozens or even hundreds
of cores, cpufreq polling sounds like a bad idea.
Especially if the CPUs do achieve the same or even
better performance/power results via entering C-states quickly.

I would like to come up with a init_default_governor()
or similar function which choses the performance governor
for such CPUs.
Hm, maybe it could get a driver callback, then this one could
be picked up by acpi-cpufreq (and powernow-k8 if applicable)
and those drivers could choose the right governor for the
platform/cpu.

Ideally identifying the CPUs where performance governor should get
used is a one liner checking for a cpu flag.
But this might not get that easy? CPU family/model would need
maintenance if there is no cpu flag/feature to test for.

Just some ideas..., if it's doable with some lines of code without
the need of maintaining/adding new cpu families, I'd like to have
a better default behavior.

One main problem I am facing is: Measuring power consumption
in different workloads.

I can measure the power consumption in idle (deeper sleep
states entered) when CPU frequency is set to lowest and highest
and compare. If both are the same, the CPU is a good candidate
to not do OS controlled CPU frequency scaling.

What do you think?

Thanks,

   Thomas

             reply	other threads:[~2012-07-24 13:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 13:15 Thomas Renninger [this message]
2012-07-24 13:22 ` Disable cpufreq on modern X86 processors Andreas Herrmann
2012-07-26 13:39   ` Andre Przywara
2012-07-26 13:57     ` Arjan van de Ven
2012-07-24 13:23 ` Arjan van de Ven

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=201207241515.15324.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=andreas.herrmann3@amd.com \
    --cc=arjan@linux.intel.com \
    --cc=borislav.petkov@amd.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=lenb@kernel.org \
    --cc=mgalbraith@suse.de \
    /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