On Fri, Jul 30, 2010 at 11:56:25AM +0900, Iram Shahzad wrote: > Mel Gorman wrote: >>> My question is: why does it depend on CONFIG_HUGETLB_PAGE? >> >> Because as the Kconfig says "Allows the compaction of memory for the >> allocation of huge pages.". Depending on compaction to satisfy other >> high-order allocation types is not likely to be a winning strategy. > > Please could you elaborate a little more why depending on > compaction to satisfy other high-order allocation is not good. > At the very least, it's not a situation that has been tested heavily and because other high-order allocations are typically not movable. In the worst case, if they are both frequent and long-lived they *may* eventually encounter fragmentation-related problems. This uncertainity is why it's not good. It gets worse if there is no swap as eventually all movable pages will be compacted as much as possible but there still might not be enough contiguous memory for a high-order page because other pages are pinned. >>> Is it wrong to use it on ARM by disabling CONFIG_HUGETLB_PAGE? >>> >> >> It depends on why you need compaction. If it's for some device that >> requires high-order allocations (particularly if they are atomic), then >> it's not likely to work very well in the long term. > > Would you please elaborate on this as well. > In the case the allocation is atomic and there isn't a suitable page available, compaction cannot occur either. Given enough uptime, there will be failure reports as a result. Avoid high-order allocations where possible. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>