Messages in this thread | | | Subject | Re: [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages using cma | From | Mike Kravetz <> | Date | Tue, 10 Mar 2020 13:29:09 -0700 |
| |
On 3/10/20 1:15 PM, Rik van Riel wrote: > On Tue, 2020-03-10 at 13:11 -0700, Mike Kravetz wrote: >> On 3/10/20 12:46 PM, Rik van Riel wrote: >>> >>> How would that work for architectures that have multiple >>> possible hugetlbfs gigantic page sizes, where the admin >>> can allocate different numbers of differently sized pages >>> after bootup? >> >> For hugetlb page reservations at boot today, pairs specifying size >> and >> quantity are put on the command line. For example, >> hugepagesz=2M hugepages=512 hugepagesz=1G hugepages=64 >> >> We could do something similiar for CMA. >> hugepagesz=512M hugepages_cma=256 hugepagesz=1G hugepages_cma=64 >> >> That would make things much more complicated (implies separate CMA >> reservations per size) and may be overkill for the first >> implementation. >> >> Perhaps we limit CMA reservations to one gigantic huge page >> size. The >> architectures would need to define the default and there could be a >> command line option to override. Something like, >> default_cmapagesz= analogous to today's default_hugepagesz=. Then >> hugepages_cma= is only associated with that default gigantic huge >> page >> size. >> >> The more I think about it, the more I like limiting CMA reservations >> to >> only one gigantic huge page size (per arch). > > Why, though? > > The cma_alloc function can return allocations of different > sizes at the same time. > > There is no limitation in the underlying code that would stop > a user from allocating hugepages of different sizes through > sysfs.
True, there is no technical reason.
I was only trying to simplify the setup and answer the outstanding questions. - What alignment to use for reservations? - What is minimum size of reservations?
If only one gigantic page size is supported, the answer is simple. In any case, I think input from arch specific code will be needed. -- Mike Kravetz
> Allowing the system administrator to allocate a little extra > memory for the CMA pool could also allow us to work around > initial issues of compaction/migration failing to move some > of the pages, while we play whack-a-mole with the last corner > cases.
| |