linux-kernel - Memory Power Management - Was: Re: [linux-pm] Ottawa Linux Power Management Summit, July 22, 2008

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] [day] [month] [year] [list]

Message-Id: <1217634617.28090.82.camel@localhost>
Date:	Sat, 02 Aug 2008 02:50:17 +0300
From:	Igor Stoppa <igor.stoppa@...ia.com>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Linux Power Management List <linux-pm@...ts.osdl.org>,
	linux-acpi@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Memory Power Management - Was: Re: [linux-pm] Ottawa Linux Power
	Management Summit, July 22, 2008 - Minutes

Hi,
On Fri, 2008-08-01 at 17:05 -0400, ext Len Brown wrote:

[snip]

> Memory power management
> -----------------------
> 
> We discussed the challenges to memory power management
> on servers.  Specifically, power-friendly interleaving
> and the inability to migrate/free pages used by the kernel.
> 
> HSuperH may benefit soonest here b/c
> not stopped by interleaving issue.
> NUMA memory node for accounting.
> 
> Paul Mundt, using on SH
> needs to be dynamic b/c cores turned on/off dynamically.
> 
> This is a common requirement between embedded and server platform
> Consensus was to work on a common framework for page
> placement based on frequency of reference.
> 
> Physical address to memory module (DIMM) information needs to be
> exported by the platform to get started on any memory PM techniques.
> Currently there is no information about fine grain memory topology
> except for NUMA systems at node level.

I am interested about the embedded part: last year Nokia had an
evaluation done on the memory chip used for n800, which can be set to
perform self refresh of 1/4, 1/2 and 1/1 of the available SDRAM.

The finding was that on average the energy spent for rearranging the
pages so that those going to be preserved would be in the memory area
kept in self refresh + the energy spent for reloading the other pages
from flash was significantly higher than just using self refresh for the
entire SDRAM.

I can dig out the details if there is interest, however the SDRAM used
is the mobile type with relatively low leakages and speed (133MHz).

I'd be interested to know what's the case with SH and if there has been
any study/verification.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
--
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/