On 3/9/21 9:50 AM, David Hildenbrand wrote: > On 09.03.21 18:11, Mike Kravetz wrote: >> On 3/9/21 1:01 AM, David Hildenbrand wrote: >>> On 09.03.21 01:18, Mike Kravetz wrote: >>>> To address these issues, introduce the concept of hugetlb page demotion. >>>> Demotion provides a means of 'in place' splitting a hugetlb page to >>>> pages of a smaller size. For example, on x86 one 1G page can be >>>> demoted to 512 2M pages. Page demotion is controlled via sysfs files. >>>> - demote_size Read only target page size for demotion >>>> - demote Writable number of hugetlb pages to be demoted >>>> >>>> Only hugetlb pages which are free at the time of the request can be demoted. >>>> Demotion does not add to the complexity surplus pages. Demotion also honors >>>> reserved huge pages. Therefore, when a value is written to the sysfs demote >>>> file that value is only the maximum number of pages which will be demoted. >>>> It is possible fewer will actually be demoted. >>>> >>>> If demote_size is PAGESIZE, demote will simply free pages to the buddy >>>> allocator. >>> >>> With the vmemmap optimizations you will have to rework the vmemmap layout. How is that handled? Couldn't it happen that you are half-way through splitting a PUD into PMDs when you realize that you cannot allocate vmemmap pages for properly handling the remaining PMDs? What would happen then? >>> >>> Or are you planning on making both features mutually exclusive? >>> >>> Of course, one approach would be first completely restoring the vmemmap for the whole PUD (allocating more pages than necessary in the end) and then freeing individual pages again when optimizing the layout per PMD. >>> >> >> You are right about the need to address this issue. Patch 3 has the >> comment: >> >> + /* >> + * Note for future: >> + * When support for reducing vmemmap of huge pages is added, we >> + * will need to allocate vmemmap pages here and could fail. >> + */ >> > > I only skimmed over the cover letter so far. :) > >> The simplest approach would be to restore the entire vmemmmap for the >> larger page and then delete for smaller pages after the split. We could >> hook into the existing vmemmmap reduction code with just a few calls. >> This would fail to demote/split, if the allocation fails. However, this >> is not optimal. >> >> Ideally, the code would compute how many pages for vmemmmap are needed >> after the split, allocate those and then construct vmmemmap >> appropriately when creating the smaller pages. >> >> I think we would want to always do the allocation of vmmemmap pages up >> front and not even start the split process if the allocation fails. No >> sense starting something we may not be able to finish. >> > > Makes sense. > > Another case might also be interesting: Assume you allocated a gigantic page via CMA and denoted it to huge pages. Theoretically (after Oscar's series!), we could come back later and re-allocate a gigantic page via CMA, migrating all now-hugepages out of the CMA region. Would require telling CMA that that area is effectively no longer allocated via CMA (adjusting accounting, bitmaps, etc). > I need to take a close look at Oscar's patches. Too many thing to look at/review :) This series does take into account gigantic pages allocated in CMA. Such pages can be demoted, and we need to track that they need to go back to CMA. Nothing super special for this, mostly a new hugetlb specific flag to track such pages. > That would actually be a neat use case to form new gigantic pages later on when necessary :) > > But I assume your primary use case is denoting gigantic pages allocated during boot, not via CMA. > > Maybe you addresses that already as well :) Yup. > >> I purposely did not address that here as first I wanted to get feedback >> on the usefulness demote functionality. >> > > Makes sense. I think there could be some value in having this functionality. Gigantic pages are rare and we might want to keep them as long as possible (and as long as we have sufficient free memory). But once we need huge pages (e.g., smaller VMs, different granularity requiremets), we could denote. > That is exactly the use case of one our product groups. Hoping to get feedback from others who might be doing something similar. > If we ever have pre-zeroing of huge/gigantic pages, your approach could also avoid having to zero huge pages again when the gigantic page was already zeroed. > Having a user option to pre-zero hugetlb pages is also on my 'to do' list. We now have hugetlb specific page flags to help with tracking. -- Mike Kravetz
