MySQL 8.0.40
Source Code Documentation
|
Helper struct implementing the type which represents the metadata for all types of PFS-aware page-aligned allocations, be it regular pages or huge-pages. More...
#include <page_metadata.h>
Public Types | |
using | pfs_metadata = PFS_metadata |
using | page_type_t = size_t |
Static Public Member Functions | |
static Page_type | page_type (void *data) |
Sanity check so that we can be sure that the size of our metadata segment is such so that the pointer to DATA segment is always suitably aligned (multiple of alignof(max_align_t). More... | |
static void | page_type (void *mem, Page_type type) |
Accessor to the page_type_t field. More... | |
Static Public Attributes | |
static constexpr auto | len = CPU_PAGE_SIZE |
This is how much this metadata segment will be big. More... | |
static constexpr auto | page_type_offset |
Suitably-aligned offset for PAGE-TYPE field. More... | |
Helper struct implementing the type which represents the metadata for all types of PFS-aware page-aligned allocations, be it regular pages or huge-pages.
Concrete implementations such as Page_alloc_pfs or Large_page_alloc_pfs are both implemented in terms of this basic building block. This is one way which enables an easier implementation of higher-kinded convenience library functions, e.g. huge-page allocation with fallback to regular pages.
Memory layout representation looks like the following:
\ ^ \ 0 | \ | CPU_PAGE_SIZE - 1 |
OWNER field encodes the owning thread. DATALEN field encodes total size of memory consumed and not only the size of the DATA segment. KEY field encodes the PFS/PSI key.
PAGE-TYPE field encodes the type of page this memory is backed up with.
VARLEN is the leftover variable-length segment that specialized implementations can further make use of by deducing its size from the following formulae: abs(CPU_PAGE_SIZE - sizeof(PFS-META-OFFSET) - sizeof(PFS-META)). In code that would be std::abs(CPU_PAGE_SIZE - PFS_metadata::size). Not used by this implementation.
PFS-META-OFFSET, strictly speaking, isn't necessary in this case of system-pages, where alignment is always known in compile-time and thus the offset we will be storing into the PFS-META-OFFSET field is always going to be the same for the given platform. So, rather than serializing this piece of information into the memory as we do right now, we could very well be storing it into the compile-time evaluated constexpr constant. The reason why we don't do it is that there is no advantage (*) of doing so while we would be introducing a disadvantage of having to maintain separate specialization of PFS_metadata and code would be somewhat more fragmented.
(*) Extra space that we need to allocate in order to be able to fit the PFS_metadata is going to be the same regardless if there is PFS-META-OFFSET field or not. This is due to the fact that PFS-META segment alone is larger than alignof(max_align_t) so in order to keep the DATA segment suitably aligned (% alignof(max_align_t) == 0) we must choose the size for the whole PFS segment that is a multiple of alignof(max_align_t).
PFS-META-OFFSET is a field which allows us to recover the pointer to PFS-META segment from a pointer to DATA segment.
using ut::detail::Page_alloc_metadata_pfs::page_type_t = size_t |
|
inlinestatic |
Sanity check so that we can be sure that the size of our metadata segment is such so that the pointer to DATA segment is always suitably aligned (multiple of alignof(max_align_t).
Accessor to the page_type_t field. Returns its value.
[in] | data | Pointer to the DATA segment. |
|
inlinestatic |
Accessor to the page_type_t field.
Sets its value.
[in] | mem | Pointer to the memory, usually allocated through large_page_alloc or page_alloc. |
[in] | type | New value to be set into the field. |
|
staticconstexpr |
This is how much this metadata segment will be big.
|
staticconstexpr |
Suitably-aligned offset for PAGE-TYPE field.