[lkml]   [2010]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/4] big chunk memory allocator v4
    On Tue, 23 Nov 2010 16:46:03 +0100
    Michał Nazarewicz <> wrote:

    > A few things than:
    > 1. As Felipe mentioned, on ARM it is often desired to have the memory
    > mapped as non-cacheable, which most often mean that the memory never
    > reaches the page allocator. This means, that alloc_contig_pages()
    > would not be suitable for cases where one needs such memory.
    > Or could this be overcome by adding the memory back as highmem? But
    > then, it would force to compile in highmem support even if platform
    > does not really need it.
    > 2. Device drivers should not by themselves know what ranges of memory to
    > allocate memory from. Moreover, some device drivers could require
    > allocation different buffers from different ranges. As such, this
    > would require some management code on top of alloc_contig_pages().
    > 3. When posting hwmem, Johan Mossberg mentioned that he'd like to see
    > notion of "pinning" chunks (so that not-pinned chunks can be moved
    > around when hardware does not use them to defragment memory). This
    > would again require some management code on top of
    > alloc_contig_pages().
    > 4. I might be mistaken here, but the way I understand ZONE_MOVABLE work
    > is that it is cut of from the end of memory. Or am I talking nonsense?
    > My concern is that at least one chip I'm working with requires
    > allocations from different memory banks which would basically mean that
    > there would have to be two movable zones, ie:
    > +-------------------+-------------------+
    > | Memory Bank #1 | Memory Bank #2 |
    > +---------+---------+---------+---------+
    > | normal | movable | normal | movable |
    > +---------+---------+---------+---------+

    > So even though I'm personally somehow drawn by alloc_contig_pages()'s
    > simplicity (compared to CMA at least), those quick thoughts make me think
    > that alloc_contig_pages() would work rather as a backend (as Kamezawa
    > mentioned) for some, maybe even tiny but still present, management code
    > which would handle "marking memory fragments as ZONE_MOVABLE" (whatever
    > that would involve) and deciding which memory ranges drivers can allocate
    > from.
    > I'm also wondering whether alloc_contig_pages()'s first-fit is suitable but
    > that probably cannot be judged without some benchmarks.

    I'll continue to update patches, you can freely reuse my code and integrate
    this set to yours. I works for this firstly for EMBEDED but I want this to be
    a _generic_ function for gerenal purpose architecture.
    There may be guys who want 1G page on a host with tons of free memory.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-11-24 01:45    [W:0.026 / U:0.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site