From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Andi Kleen <andi@firstfloor.org>
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: Fri, 1 Jun 2007 15:39:31 -0700 [thread overview]
Message-ID: <20070601223931.GB13751@tree.beaverton.ibm.com> (raw)
In-Reply-To: <p73ejkvbblo.fsf@bingen.suse.de>
On Fri, Jun 01, 2007 at 11:37:07PM +0200, Andi Kleen wrote:
> > On Thu, Mar 29, 2007 at 06:06:22PM -0700, Pallipadi, Venkatesh wrote:
> 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?
Yep, I adjust scaling_max_frequency as needed. The adjustment is
currently done once per minute, though I've noticed that the BMC power meter
itself can react in about 10-15 seconds. Incidentally, the ACPI battery
meter seems to react in about 2-5 seconds on my T40. I suspect that I
could lower that adjustment interval even further, though on the AMD box
(x3755) the power meter is slow to read under high loads.
> 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.
Yep, this is true too. Right now I'm using CPU offlining as a clumsy
mechanism to force a CPU into idle state; even with the incorrect
assumption that affected_cpus applies to forced idleness, it seems to
work ok. We can end up losing more cores than we need to, but so far it
has always been the case that we don't offline cores until we've run out
of lower p-states on all cores. But I imagine with 80-core behemoths
on the way, I ought to fix this particular bug somehow. It will
probably involve adding a transition rule for each of the
non-lowest-numbered CPUs in a cpufreq domain between 0 and whatever
speed the lowest numbered CPU is in that domain is running at.
--D
next prev parent reply other threads:[~2007-06-01 22:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 0:43 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
2007-06-01 22:39 ` Darrick J. Wong [this message]
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=20070601223931.GB13751@tree.beaverton.ibm.com \
--to=djwong@us.ibm.com \
--cc=andi@firstfloor.org \
--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
all inboxes | Powered by JetHome®