public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@nokia.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Linux Power Management List <linux-pm@lists.osdl.org>,
	linux-acpi@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Memory Power Management - Was: Re: [linux-pm] Ottawa Linux Power Management Summit, July 22, 2008 - Minutes
Date: Sat, 02 Aug 2008 02:50:17 +0300	[thread overview]
Message-ID: <1217634617.28090.82.camel@localhost> (raw)
In-Reply-To: <alpine.LFD.1.10.0808011704490.3011@localhost.localdomain>

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

      reply	other threads:[~2008-08-02  0:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LFD.1.10.0807260205300.24819@localhost.localdomain>
2008-08-01 21:05 ` Ottawa Linux Power Management Summit, July 22, 2008 - Minutes Len Brown
2008-08-01 23:50   ` Igor Stoppa [this message]

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=1217634617.28090.82.camel@localhost \
    --to=igor.stoppa@nokia.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    /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