On 3/10/21 8:23 AM, Michal Hocko wrote: > On Mon 08-03-21 16:18:52, Mike Kravetz wrote: > [...] >> Converting larger to smaller hugetlb pages can be accomplished today by >> first freeing the larger page to the buddy allocator and then allocating >> the smaller pages. However, there are two issues with this approach: >> 1) This process can take quite some time, especially if allocation of >> the smaller pages is not immediate and requires migration/compaction. >> 2) There is no guarantee that the total size of smaller pages allocated >> will match the size of the larger page which was freed. This is >> because the area freed by the larger page could quickly be >> fragmented. > > I will likely not surprise to show some level of reservation. While your > concerns about reconfiguration by existing interfaces are quite real is > this really a problem in practice? How often do you need such a > reconfiguration? In reply to one of David's comments, I mentioned that we have a product group with this use case today. They use hugetlb pages to back VMs, and preallocate a 'best guess' number of pages of each each order. They can only guess how many pages of each order are needed because they are responding to dynamic requests for new VMs. When they find themselves in this situation today, they free 1G pages to buddy and try to allocate the corresponding number of 2M pages. The concerns above were mentioned/experienced by this group. Part of the reason for the RFC was to see if others might have similar use cases. With newer x86 processors, I hear about more people using 1G hugetlb pages. I also hear about people using hugetlb pages to back VMs. So, was thinking others may have similar use cases? > Is this all really worth the additional code to something as tricky as > hugetlb code base? > The 'good news' is that this does not involve much tricky code. It only demotes free hugetlb pages. Of course, it is only worth it the new code is actually going to be used. I know of at least one use case. -- Mike Kravetz
