Allocation routines which are purposed for allocating memory through the means of what is known as large (huge) pages.
More...
Allocation routines which are purposed for allocating memory through the means of what is known as large (huge) pages.
large_page_aligned_alloc() and large_page_aligned_free() are taking care of OS specific details and Large_page_alloc is a convenience wrapper which only makes the use of large pages more ergonomic so that it serializes the actual size being allocated into the raw memory. This size is then automagically deduced when large page memory is being freed. Otherwise, client code would have been responsible to store and keep that value somewhere until it frees the large page memory segment. Additionally, information on type of page used to back up requested allocation is also serialized into the memory allowing to build higher-kinded abstractions more easily. See ut::malloc_large_page with option to fallback to regular pages through ut::malloc_page.
Cost associated with this abstraction is the size of a single CPU page. In terms of virtual memory, especially in 64-bit address space, this cost is negligible. In practice this means that for each N huge-page sized allocation request, application code will get to use CPU_PAGE_SIZE bytes less. In other words, for a request that is backed up by three 2MiB huge-pages, application code will get to use 3 * 2MiB - CPU_PAGE_SIZE of total bytes. CPU_PAGE_SIZE is normally 4K but some architectures such as SPARC have it set to 8K. ARM64 can be set to 4K, 8K or 64K.
Memory layout representation looks like the following:
| PAGE-ALLOC-METADATA | ... DATA ... |
^ ^ | | | | | ptr (large-page) to be returned to call-site
|
| DATALEN | PAGE-TYPE | VARLEN |
\ \ 0 \ CPU_PAGE_SIZE - 1
For details on DATALEN, PAGE-TYPE and VARLEN fields see Page_alloc_metadata.
DATA is an actual page-aligned (!) segment backed by large (huge) page memory that will be returned to the call-site and which the client code will be able to use for the application data.