On Fri, 19 Nov 2010 17:10:33 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > Hi, this is an updated version. > > No major changes from the last one except for page allocation function. > removed RFC. > > Order of patches is > > [1/4] move some functions from memory_hotplug.c to page_isolation.c > [2/4] search physically contiguous range suitable for big chunk alloc. > [3/4] allocate big chunk memory based on memory hotplug(migration) technique > [4/4] modify page allocation function. > > For what: > > I hear there is requirements to allocate a chunk of page which is larger than > MAX_ORDER. Now, some (embeded) device use a big memory chunk. To use memory, > they hide some memory range by boot option (mem=) and use hidden memory > for its own purpose. But this seems a lack of feature in memory management. > > This patch adds > alloc_contig_pages(start, end, nr_pages, gfp_mask) > to allocate a chunk of page whose length is nr_pages from [start, end) > phys address. This uses similar logic of memory-unplug, which tries to > offline [start, end) pages. By this, drivers can allocate 30M or 128M or > much bigger memory chunk on demand. (I allocated 1G chunk in my test). > > But yes, because of fragmentation, this cannot guarantee 100% alloc. > If alloc_contig_pages() is called in system boot up or movable_zone is used, > this allocation succeeds at high rate. So this is an alternatve implementation for the functionality offered by Michal's "The Contiguous Memory Allocator framework". > I tested this on x86-64, and it seems to work as expected. But feedback from > embeded guys are appreciated because I think they are main user of this > function. >From where I sit, feedback from the embedded guys is *vital*, because they are indeed the main users. Michal, I haven't made a note of all the people who are interested in and who are potential users of this code. Your patch series has a billion cc's and is up to version 6. Could I ask that you review and test this code, and also hunt down other people (probably at other organisations) who can do likewise for us? Because until we hear from those people that this work satisfies their needs, we can't really proceed much further. Thanks. -- 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>