On Tue, 23 Nov 2010 16:46:03 +0100 MichaÅ Nazarewicz <m.nazarewicz@xxxxxxxxxxx> 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>