Re: [Results] [RFC PATCH v4 00/40] mm: Memory Power Management
From: Arjan van de Ven
Date: Thu Sep 26 2013 - 11:24:02 EST
On 9/25/2013 6:21 PM, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote:
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
and back into full operation. Please do discuss and quantify that to
the best of your knowledge.
On Sandy Bridge the memry wakeup overhead is really small. It's on by default
in most setups today.
btw note that those kind of memory power savings are content-preserving,
so likely a whole chunk of these patches is not actually needed on SNB
(or anything else Intel sells or sold)
(head spinning a bit). Could you please expand on this rather a lot?
so there is two general ways to save power on memory
one way keeps the content of the memory there
the other way loses the content of the memory.
in the first type, there are degrees of power savings (each with their own costs), and the mechanism to enter/exit
tends to be fully automatic, e.g. OS invisible. (and generally very very fast.. measured in low numbers of nanoseconds)
in the later case the OS by nature has to get involved and actively free the content of the memory prior to
setting the power level lower (and thus lose the content).
on the machines Srivatsa has been measuring, only the first type exists... e.g. content is preserved.
at which point, I am skeptical that it is worth spending a lot of CPU time (and thus power!) to move stuff around
or free memory (e.g. reduce disk cache efficiency -> loses power as well).
the patches posted seem to go to great lengths doing these kind of things.
to get the power savings, my deep suspicion (based on some rudimentary experiments done internally to Intel
earlier this year) is that it is more than enough to have "statistical" level of "binding", to get 95%+ of
the max theoretical power savings.... basically what todays NUMA policy would do.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/