lkml.org 
[lkml]   [2010]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] big chunk memory allocator v4
On Tue, 23 Nov 2010 16:46:03 +0100
Michał Nazarewicz <m.nazarewicz@samsung.com> 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 |
> +---------+---------+---------+---------+
>
yes.

> 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.


Thanks,
-Kame


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-11-24 01:45    [from the cache]
©2003-2011 Jasper Spaans