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. 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. -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
