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 from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
