* Dave Hansen [off-list ref] [2011-06-29 10:06:24]:

I was kinda hoping for something a bit simpler than that.  I'd boil down
what you were saying to this:

     1. The kernel must be aware of how the pieces of hardware are
        mapped in to the system's physical address space
     2. The kernel must have a mechanism in place to minimize access to
        specific pieces of hardware 

          (mainly by controlling allocations and reclaim)
                

     3. For destructive power-down operations, the kernel should have a
        mechanism in place to ensure that no valuable data is contained
        in the memory to be powered down.

Is that complete?

At a high level these are the main requirements, except that different
operations/features can happen at different/higher granularity.  The
infrastructure should be able to related groups of regions and act
upon for a specific optimization.  Like granularity for (2) may be
512MB, while (3) could be a pair of 512MB blocks. This is relatively
a minor issue to solve.

On Wed, 2011-06-29 at 18:30 +0530, Ankita Garg wrote:

quoted

1) Dynamic Power Transition: The memory controller can have the ability
to automatically transition regions of memory into lower power states
when they are devoid of references for a pre-defined threshold amount of
time. Memory contents are preserved in the low power states and accessing
memory that is at a low power state takes a latency hit.

2) Dynamic Power Off: If a region is free/unallocated, the software can
indicate to the controller to completely turn off power to a certain
region. Memory contents are lost and hence the software has to be
absolutely sure about the usage statistics of the particular region. This
is a runtime capability, where the required amount of memory can be
powered 'ON' to match the workload demands.

3) Partial Array Self-Refresh (PASR): If a certain regions of memory is
free/unallocated, the software can indicate to the controller to not
refresh that region when the system goes to suspend-to-ram state and
thereby save standby power consumption.

(3) is simply a subset of (2), but with the additional restriction that
the power off can only occur during a suspend operation.  

Let's say we fully implemented support for (2).  What would be missing
to support PASR?

The similarity between (2) and (3) here is the need for accurate
statistics to know allocation status. The difference is the
actuation/trigger part... in case of (2) the trigger would happen
during allocation/free while in case of (3) it happens only at suspend
time.  Also the granularity could be different, generally PASR is very
fine grain as compared for power-off at controller level.

We can combine them and look at just how to track allocations at
different (or multiple) physical boundaries.

--Vaidy