lkml.org 
[lkml]   [2011]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 01/10] mm: Introduce the memory regions data structure
    From
    Date
    On Sun, 2011-05-29 at 13:46 +0530, Ankita Garg wrote:
    > > It's worth noting that we already do targeted reclaim on boundaries
    > > other than zones. The lumpy reclaim and memory compaction logically do
    > > the same thing. So, it's at least possible to do this without having
    > > the global LRU designed around the way you want to reclaim.
    > >
    > My understanding maybe incorrect, but doesn't both lumpy reclaim and
    > memory compaction still work under zone boundary ? While trying to free
    > up higher order pages, lumpy reclaim checks to ensure that pages that
    > are selected do not cross zone boundary. Further, compaction walks
    > through the pages in a zone and tries to re-arrange them.

    I'm asserting that we don't need memory regions in the

    pgdat->regions[]->zones[]

    layout to do what you're asking for.

    Lumpy reclaim is limited to a zone because it's trying to satisfy and
    allocation request that came in for *THAT* *ZONE*. It's useless to go
    clear out other zones. In your case, you don't care about zone
    boundaries: you want to reclaim things regardless.

    There was a "cma: Contiguous Memory Allocator added" patch posted a bit
    ago to linux-mm@. You might want to take a look at it for some
    inspiration.

    I think you also need to clearly establish here why any memory that
    you're going to want to power off can't use (or shouldn't use)
    ZONE_MOVABLE. It seems a bit silly to have it there, and ignore it for
    such a similar use case. Memory hot-remove and power-down are not
    horrifically different beasts.

    BTW, that's probably something else to add to your list: make sure
    mem_map[]s for memory in a region get allocated *in* that region.

    -- Dave



    \
     
     \ /
      Last update: 2011-05-31 19:37    [W:4.442 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site