From: Andi Kleen <andi@firstfloor.org>
To: "Darrick J. Wong" <djwong@us.ibm.com>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE_HW?
Date: 01 Jun 2007 23:37:07 +0200 [thread overview]
Message-ID: <p73ejkvbblo.fsf@bingen.suse.de> (raw)
In-Reply-To: <20070601184342.GA13751@tree.beaverton.ibm.com>
"Darrick J. Wong" <djwong@us.ibm.com> writes:
> On Thu, Mar 29, 2007 at 06:06:22PM -0700, Pallipadi, Venkatesh wrote:
> > thought of
> > making affected CPUs show the dependency in case of hw coord, but
> > retaining the percpu
> > control. But, it seemed complicated change for something that is
> > cosmetic.
>
> Actually, it's not so cosmetic any more. Our newest servers have a
> power meter that measures power consumption, and I'm writing a program
> to measure the power cost of various cpufreq transitions in order to
> enforce a power cap.
How would that work? You would adjust the power cap dynamically during
runtime based on the power meter feedback? How long would
the adjustment interval be?
> Due to the under-reporting in affected_cpus, the
> app thinks that (taking your example above) CPUs 0 and 2 can be
> controlled independently. Thus, a p-state transition of (x, x) ->
> (x, x-1) yields no energy saving at all, while (x, x-1) -> (x-1, x-1)
> does. My program considers the effects of a single CPU's transition
> independently of which CPU it is and without considering what
> frequencies the other CPUs are operating at, which means that it will
> conclude that the cost of increasing speed (or the reward for decreasing
> it) is half of what it is ... sort of. It's mildly broken as a result,
> though amusingly enough it still seems to work ok. I suspect that it
> might flail around trying to hit a cap a bit more than it would if
> affected_cpus were more accurate.
Not sure affected CPUs is accurate enough for your purposes anyways.
It cannot express "other core can be independent if I'm idle, otherwise not"
which is common on Intel systems.
-Andi
next prev parent reply other threads:[~2007-06-01 20:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 0:43 Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE_HW? Darrick J. Wong
2007-03-30 1:06 ` Pallipadi, Venkatesh
2007-06-01 18:43 ` Darrick J. Wong
2007-06-01 21:37 ` Andi Kleen [this message]
2007-06-01 22:39 ` Darrick J. Wong
2007-06-02 1:59 ` Pallipadi, Venkatesh
2007-06-02 6:43 ` Dave Jones
2007-06-02 14:19 ` Dependent CPU core speed reporting not updated withCPUFREQ_SHARED_TYPE_HW? Pallipadi, Venkatesh
2007-06-04 17:07 ` Darrick J. Wong
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=p73ejkvbblo.fsf@bingen.suse.de \
--to=andi@firstfloor.org \
--cc=djwong@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=venkatesh.pallipadi@intel.com \
/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