Re: [PATCH 0/4] big chunk memory allocator v4

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Tue, 23 Nov 2010 16:46:03 +0100
MichaA? 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>