linux-kernel - Re: Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070601223931.GB13751@tree.beaverton.ibm.com>
Date:	Fri, 1 Jun 2007 15:39:31 -0700
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE_HW?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/