MEMKIND_PMEM(3)

💖 MEMKIND_PMEM 💖

okay bestie, sit down, hydrate, and let's talk about memkind_pmem — it's the memkind operations for file-backed memory. and bestie. it is EXPERIMENTAL. like, the API is experimental, and the header file itself can get changed (yes, even in ways that break your code, non-backward-compatible style 😭) or straight up removed. so manifest accordingly. no cap.

✨ NAME ✨

memkind_pmem — file-backed memory memkind operations, duh 💅

⚠️ heads up: this is EXPERIMENTAL API. the functionality and the header file itself can be changed (including non-backward compatible changes) or removed. i'm not being dramatic, that's literally the warning. 🙈

🌸 SYNOPSIS 🌸

int memkind_pmem_create(struct memkind *kind, struct memkind_ops *ops,
const char *name);
int memkind_pmem_destroy(struct memkind *kind);
void *memkind_pmem_mmap(struct memkind *kind, void *addr, size_t size);
int memkind_pmem_get_mmap_flags(struct memkind *kind, int *flags);
int memkind_pmem_validate_dir(const char *dir);

🦋 DESCRIPTION 🦋

the pmem memory memkind operations let you build memory kinds on top of memory-mapped files, periodt. they support traditional volatile memory allocation in a way that's similar to the libvmem(3) library. under the hood it uses the mmap(2) system call to create a pool of volatile memory. and here's the cute part — that memory can have different attributes depending on which file system is holding the memory-mapped files. (see also http://pmem.io/pmdk/libvmem.)

the pmem kinds are most useful when used with DAX — that's direct mapping of persistent memory, which is memory-addressable persistent storage that supports load/store access without being paged via the system page cache. a Persistent Memory-aware file system is typically what you'd use to provide this kind of access. iykyk ✨

the most convenient way to create pmem kinds is to use memkind_create_pmem() or memkind_create_pmem_with_config() (peep memkind(3)).

• memkind_pmem_create() — this is the implementation of the memkind "create" operation for file-backed memory kinds. it allocates a space for some pmem-specific metadata, then calls memkind_arena_create() (see memkind_arena(3)). 🎀
• memkind_pmem_destroy() — the implementation of the memkind "destroy" operation for file-backed memory kinds. it releases all of the resources that memkind_pmem_create() allocated and lets the file system space be reclaimed. it's giving spring cleaning 🧹
• memkind_pmem_mmap() — allocates the file system space for a block of size bytes in the memory-mapped file associated with the given kind. the addr hint is ignored (sorry girl, it said what it said 💀). the return value is the address of the mapped memory region, or MAP_FAILED in the case of an error.
• memkind_pmem_get_mmap_flags() — sets flags to MAP_SHARED. see mmap(2) for more info about these flags.
• memkind_pmem_validate_dir() — returns zero if the file created in the specified pmem_dir supports DAX (direct mapping of persistent memory), or an error code from the ERRORS if not. vibe check on your directory, basically 🫶

🌈 MEMKIND_PMEM_CHUNK_SIZE 🌈

• MEMKIND_PMEM_CHUNK_SIZE — the size of the PMEM chunk size. (yes that's the whole description, it is what it is ⭐)

👑 COPYRIGHT 👑

Copyright (C) 2015 - 2020 Intel Corporation. All rights reserved.

💜 SEE ALSO 💜

memkind(3), memkind_arena(3), memkind_default(3), memkind_hbw(3), memkind_hugetlb(3), libvmem(3), jemalloc(3), mbind(2), mmap(2)

and that's the whole page bestie, you ate it 💅✨ this one came from Intel Corporation, dated 2015-04-21, and it lives in the MEMKIND_PMEM section of your manual. go forth and mmap responsibly, ily 🎀🦋🌸