* Pekka Enberg [off-list ref] [2011-07-06 12:01:45]:

On Wed, Jul 6, 2011 at 11:45 AM, Pekka Enberg [off-list ref] wrote:

quoted

Hi Ankita,

[ I don't really know anything about memory power management but
?here's my two cents since you asked for it. ]

On Wed, Jun 29, 2011 at 4:00 PM, Ankita Garg [off-list ref] wrote:

quoted

I) Dynamic Power Transition

The goal here is to ensure that as much as possible, on an idle system,
the memory references do not get spread across the entire RAM, a problem
similar to memory fragmentation. The proposed approach is as below:

1) One of the first things is to ensure that the memory allocations do
not spill over to more number of regions. Thus the allocator needs to
be aware of the address boundary of the different regions.

Why does the allocator need to know about address boundaries? Why
isn't it enough to make the page allocator and reclaim policies favor using
memory from lower addresses as aggressively as possible? That'd mean
we'd favor the first memory banks and could keep the remaining ones
powered off as much as possible.

IOW, why do we need to support scenarios such as this:

? bank 0 ? ? bank 1 ? bank 2 ? ?bank3
?| online ?| offline | online ?| offline |

instead of using memory compaction and possibly something like the
SLUB defragmentation patches to turn the memory map into this:

? bank 0 ? ? bank 1 ? bank 2 ? bank3
?| online ?| online ?| offline | offline |

quoted

2) At the time of allocation, before spilling over allocations to the
next logical region, the allocator needs to make a best attempt to
reclaim some memory from within the existing region itself first. The
reclaim here needs to be in LRU order within the region. ?However, if
it is ascertained that the reclaim would take a lot of time, like there
are quite a fe write-backs needed, then we can spill over to the next
memory region (just like our NUMA node allocation policy now).

I think a much more important question is what happens _after_ we've
allocated and free'd tons of memory few times. AFAICT, memory
regions don't help with that kind of fragmentation that will eventually
happen anyway.

Btw, I'd also decouple the 'memory map' required for PASR from
memory region data structure and use page allocator hooks for letting
the PASR driver know about allocated and unallocated memory. That
way the PASR driver could automatically detect if full banks are
unused and power them off. That'd make memory power management
transparent to the VM regardless of whether we're using hardware or
software poweroff.

Having a 'memory map' to track blocks of memory for the purpose of
exploiting PASR is a good alternative.  However having the notion of
regions allows us to free more such banks and probably reclaim last
few pages in a block and mark it free.  A method to keep allocations
within a block and also reclaim all pages from certain blocks will
improve PASR usage apart from aiding other use cases.

Without affecting allocation and reclaim, the tracking part can be
implemented in a less intrusive way, but it will be great to design
a less intrusive method to bias the allocations and reclaims as well.

--Vaidy