Thread (68 messages) 68 messages, 13 authors, 2011-07-12

[PATCH 00/10] mm: Linux VM Infrastructure to support Memory Power Management

From: penberg@kernel.org (Pekka Enberg)
Date: 2011-07-06 09:01:47
Also in: linux-mm, lkml

On Wed, Jul 6, 2011 at 11:45 AM, Pekka Enberg [off-list ref] wrote:
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.

                        Pekka
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help