On Fri, 16 Feb 2018, Mike Kravetz wrote: > > Well that f.e brings up huge pages. You can of course > > also use this to reserve those and can then be sure that > > you can dynamically resize your huge page pools even after > > a long time of system up time. > > Yes, and no. Doesn't that assume nobody else is doing allocations > of that size? For example, I could image THP using huge page sized > reservations. The when it comes time to resize your hugetlbfs pool > there may not be enough. Although, we may quickly split THP pages > in this case. I am not sure. Yup it has a pool for everyone. Question is how to divide the loot ;-) > IIRC, Guy Shattah's use case was for allocations greater than MAX_ORDER. > This would not directly address that. A huge contiguous area (2GB) is > the sweet spot' for best performance in his case. However, I think he > could still benefit from using a set of larger (such as 2MB) size > allocations which this scheme could help with. MAX_ORDER can be increased to allow for larger allocations. IA64 has f.e. a much larger MAX_ORDER size. So does powerpc. And then the reservation scheme will work. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
