On Fri, 2010-08-27 at 17:16 +0900, KAMEZAWA Hiroyuki wrote: > > How about changing following this? > > The thing is MAX_ORDER is static. But we want to avoid too big > > MAX_ORDER of whole zones to support devices which requires big > > allocation chunk. > > So let's add MAX_ORDER into each zone and then, each zone can have > > different max order. > > For example, while DMA[32], NORMAL, HIGHMEM can have normal size 11, > > MOVABLE zone could have a 15. > > > > This approach has a big side effect? The side effect of increasing MAX_ORDER is that page allocations get more expensive since the buddy tree gets larger, yielding more splits/merges. > Hm...need to check hard coded MAX_ORDER usages...I don't think > side-effect is big. Hmm. But I think enlarging MAX_ORDER isn't an > important thing. A code which strips contiguous chunks of pages from > buddy allocator is a necessaty thing, as.. Right, once we can explicitly free the pages we want, crossing MAX_ORDER isn't too hard like you say, we can simply continue with freeing the next in order page. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
