> KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> writes: > > >> > My intention is not for allocating HUGEPAGE(> MAX_ORDER). > >> > >> I still believe using this for 1GB pages would be one of the more > >> interesting use cases. > >> > > > > I'm successfully allocating 1GB of continous pages at test. But I'm not sure > > requirements and users. How quick this allocation should be ? > > This will always be slow. Huge pages are always pre allocated > even today through a sysctl. The use case would be have > > echo XXX > /proc/sys/vm/nr_hugepages > > at runtime working for 1GB too, instead of requiring a reboot > for this. > > I think it's ok if that is somewhat slow, as long as it is not > incredible slow. Ideally it shouldn't cause a swap storm either offtopic: When I tried to increase nr_hugepages on ia64 which has 256MB hugepage architecture, sometimes I needed to wait >10 miniture if the system is under memory pressure. So, slow allocation is NOT only this contigous allocator issue. we already accept it and we should. (I doubt it can be avoidable) > > (maybe we need some way to indicate how hard the freeing code should > try?) > > I guess it would only really work well if you predefine > movable zones at boot time. > > -Andi -- 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>