From: Arjan van de Ven <arjan@linux.intel.com>
To: David C Niemi <dniemi@verisign.com>
Cc: dirk.brandewie@gmail.com, cpufreq@vger.kernel.org, rjw@sisk.pl,
deneen.t.dock@intel.com
Subject: Re: [PATCH RFC 0/1] cpufreq/x86: Add P-state driver for sandy bridge.
Date: Wed, 05 Dec 2012 13:54:20 -0800 [thread overview]
Message-ID: <50BFC28C.9060004@linux.intel.com> (raw)
In-Reply-To: <50BFBF34.3090608@verisign.com>
On 12/5/2012 1:40 PM, David C Niemi wrote:
> On 12/05/12 16:01, Arjan van de Ven wrote:
>> the idea that you can have separate policy and hardware is a big fallacy though.
>> A good policy ends up very hardware specific, and policies of the past work poorly on todays hardware
>> ("ondemand" is one of the worst case behaviors you can have on modern Intel cpus for example).
>>
>> While I appreciate the desire for some level of "preference" control, the split of policy and hardware in the
>> way cpufreq did that really isn't the way to go forward...
>>
> I don't think separating policy from implementation is a fallacy at all, it is good design practice.
thinking that policy is independent of the hardware is a fallacy.
Preference is what the user wants, sure. But a policy agent (governor) that implements that preference is very hardware
dependent.
>
> I would also say that the ondemand and performance governors are very widely used,
here's where things go wrong. "ondemand" does not indicate a power-versus-performance preference.
It indicates a certain very specific behavior of frequency selection.
A behavior that is really bad on current Intel hardware, and hurting generally in BOTH power AND performance... at the same time.
I am by no means suggesting to take away a users ability to decide where he wants to live in the
performance-versus-power scale.... but what I am suggesting is that implementing that preference is
cpu dependent; it seems to be that, at least on the past Intel roadmap, there are very fundamental changes
every 2 years that mean throwing away the actual algorithm and starting over... and I don't see that changing;
if anything it might be yearly instead of every 2 years.
something like "ondemand" got designed 10 years ago, for hardware from back then... and SandyBridge ^W"2nd generation core"
is at least 2 if not 3 fundamental technology steps ahead of that, and the assumptions behind "ondemand" are
outright not true anymore.
(ondemand design still assumes for example that frequency selection matters for when the CPU is idle.. something that's not been
true for quite some time now.. in idle the frequency and voltage are both 0.)
next prev parent reply other threads:[~2012-12-05 21:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-05 19:01 [PATCH RFC 0/1] cpufreq/x86: Add P-state driver for sandy bridge dirk.brandewie
2012-12-05 19:01 ` [PATCH RFC 1/1] " dirk.brandewie
2012-12-05 20:28 ` [PATCH RFC 0/1] " David C Niemi
2012-12-05 21:01 ` Arjan van de Ven
2012-12-05 21:40 ` David C Niemi
2012-12-05 21:54 ` Arjan van de Ven [this message]
2012-12-06 15:01 ` David C Niemi
2012-12-06 16:27 ` Arjan van de Ven
2012-12-06 17:30 ` David C Niemi
2012-12-06 17:41 ` Arjan van de Ven
2012-12-06 18:25 ` Dirk Brandewie
2012-12-06 18:41 ` David C Niemi
2012-12-06 21:35 ` Dirk Brandewie
2012-12-06 22:23 ` David C Niemi
2012-12-06 20:45 ` Rafael J. Wysocki
2012-12-06 21:15 ` Arjan van de Ven
2012-12-06 21:26 ` Rafael J. Wysocki
2012-12-06 21:34 ` Rafael J. Wysocki
2012-12-06 22:08 ` Arjan van de Ven
2012-12-06 22:53 ` Rafael J. Wysocki
2012-12-06 16:35 ` Dirk Brandewie
2012-12-06 16:49 ` Arjan van de Ven
2012-12-06 18:16 ` David C Niemi
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=50BFC28C.9060004@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=cpufreq@vger.kernel.org \
--cc=deneen.t.dock@intel.com \
--cc=dirk.brandewie@gmail.com \
--cc=dniemi@verisign.com \
--cc=rjw@sisk.pl \
/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).