[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <528276F4.7020009@linux.vnet.ibm.com>
Date: Wed, 13 Nov 2013 00:14:04 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To: Dave Hansen <dave@...1.net>
CC: Andrew Morton <akpm@...ux-foundation.org>, mgorman@...e.de,
hannes@...xchg.org, tony.luck@...el.com,
matthew.garrett@...ula.com, riel@...hat.com, arjan@...ux.intel.com,
srinivas.pandruvada@...ux.intel.com, willy@...ux.intel.com,
kamezawa.hiroyu@...fujitsu.com, lenb@...nel.org, rjw@...k.pl,
gargankita@...il.com, paulmck@...ux.vnet.ibm.com,
svaidy@...ux.vnet.ibm.com, andi@...stfloor.org,
isimatu.yasuaki@...fujitsu.com, santosh.shilimkar@...com,
kosaki.motohiro@...il.com, linux-pm@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
maxime.coquelin@...ricsson.com, loic.pallardy@...ricsson.com,
amit.kachhap@...aro.org, thomas.abraham@...aro.org,
markgross@...gnar.org
Subject: Re: [Results] [RFC PATCH v4 00/40] mm: Memory Power Management
On 11/12/2013 11:04 PM, Dave Hansen wrote:
> On 11/12/2013 12:02 AM, Srivatsa S. Bhat wrote:
>> I performed experiments on an IBM POWER 7 machine and got actual power-savings
>> numbers (upto 2.6% of total system power) from this patchset. I presented them
>> at the Kernel Summit but forgot to post them on LKML. So here they are:
>
> "upto"? What was it, actually?
Hmm? It _was_ 2.6% (Maybe my usage of the word 'upto' is misleading in that
sentence, sorry).
> Essentially what you've told us here is
> that you have a patch that tries to do some memory power management and
> that it accomplishes that. But, to what degree?
>
> Was your baseline against a kernel also booted with numa=fake=1, or was
> it a kernel booted normally?
>
The baseline kernel was also booted with numa=fake=1.
> 1. What is the theoretical power savings from memory?
I don't have that number for POWER (but I'll work on that), but referring to
the previous data from Samsung ARM boards, it was around the same number
(2.7% to 3.2 % of total system power) for memory power management using
content-preserving states. For content-destructive (power-off) states, it was
around 6.3%.
http://article.gmane.org/gmane.linux.kernel.mm/65935
> 2. How much of the theoretical numbers can your patch reach?
Honestly, the 2.6% number on the hardware that I tested is not bad at all.
As I mentioned, the base power consumption of the system (power consumption
at idle) was a bit high, so the percentage power-savings value might look small,
but nevertheless it is not insignificant. I'm trying to setup a newer prototype
hardware to test this patchset, and I expect to see better numbers on that
with the same code. By some crude initial estimates, I expect to see around
5% power-savings with the same patchset.
> 3. What is the performance impact? Does it hurt ebizzy?
>
Ebizzy numbers were quite low in both cases (vanilla and patched kernel),
in 1 digit numbers, due to the huge allocations/frees that were done on every
loop. So comparing performance with those numbers is not going to be reliable.
I'll work on detailed performance measurements after I'm done with the initial
power-savings experiments.
> You also said before:
>> On page 40, the paper shows the power-consumption breakdown for an IBM p670
>> machine, which shows that as much as 40% of the system energy is consumed by
>> the memory sub-system in a mid-range server.
>
> 2.6% seems pretty awful for such an invasive patch set if you were
> expecting 40%.
As I said, this was not the most ideal hardware to test my patches on. 128GB
is not a particularly large amount of RAM. So obviously it wont contribute a
whole lot to the total system power, atleast not as much as, say a terabyte of
RAM would. So yeah, the overall number is small, but given the relatively
modest amount of RAM installed on that machine, the savings is not ignorable.
Also, I used only 4 memory regions on this hardware, which is quite a small
number to play with. More the number of memory regions, higher the opportunity
that my patches have to cause power-savings. So I'll test with newer platforms
(with more memory regions) to see how well that goes.
Regards,
Srivatsa S. Bhat
--
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/
Powered by blists - more mailing lists