> On Fri, Dec 16, 2016 at 01:12:21AM +0000, Li, Liang Z wrote: > > There still exist the case if the MAX_ORDER is configured to a large > > value, e.g. 36 for a system with huge amount of memory, then there is only > 28 bits left for the pfn, which is not enough. > > Not related to the balloon but how would it help to set MAX_ORDER to 36? > My point here is MAX_ORDER may be configured to a big value. > What the MAX_ORDER affects is that you won't be able to ask the kernel > page allocator for contiguous memory bigger than 1<<(MAX_ORDER-1), but > that's a driver issue not relevant to the amount of RAM. Drivers won't > suddenly start to ask the kernel allocator to allocate compound pages at > orders >= 11 just because more RAM was added. > > The higher the MAX_ORDER the slower the kernel runs simply so the smaller > the MAX_ORDER the better. > > > Should we limit the MAX_ORDER? I don't think so. > > We shouldn't strictly depend on MAX_ORDER value but it's mostly limited > already even if configurable at build time. > I didn't know that and will take a look, thanks for your information. Liang > We definitely need it to reach at least the hugepage size, then it's mostly > driver issue, but drivers requiring large contiguous allocations should rely on > CMA only or vmalloc if they only require it virtually contiguous, and not rely > on larger MAX_ORDER that would slowdown all kernel allocations/freeing. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
