|Main index||Section 3||Options|
libmemstat describes each memory type using a struct memory_type, an opaque memory type accessed by the application using accessor functions in the library. libmemstat returns and updates chains of struct memory_type via a struct memory_type_list, which will be allocated by calling memstat_mtl_alloc(), and freed on completion using memstat_mtl_free(). Lists of memory types are populated via calls that query the kernel for statistics information; currently: memstat_kvm_all(), memstat_kvm_malloc(), memstat_kvm_uma(), memstat_sysctl_all(), memstat_sysctl_uma(), and memstat_sysctl_malloc(). Repeated calls will incrementally update the list of memory types, permitting tracking over time without recreating all list state. If an error is detected during a query call, error condition information may be retrieved using memstat_mtl_geterror(), and converted to a user-readable string using memstat_strerror().
Freeing the list will free all memory type data in the list, and so invalidates any outstanding pointers to entries in the list. struct memory_type entries in the list may be iterated over using memstat_mtl_first() and memstat_mtl_next(), which respectively return the first entry in a list, and the next entry in a list. memstat_mtl_find(), which will return a pointer to the first entry matching the passed parameters.
A series of accessor methods is provided to access fields of the structure, including retrieving statistics and properties, as well as setting of caller owned fields. Direct application access to the data structure fields is not supported.
Caller-owned fields are initialized to 0 or NULL when a new struct memory_type is allocated and attached to a memory type list; these fields retain their values across queries that update library-owned fields.
|Return a pointer to the name of the memory type. Memory for the name is owned by libmemstat and will be valid through a call to memstat_mtl_free(). Note that names will be unique with respect to a single allocator, but that the same name might be used by different memory types owned by different memory allocators.|
|Return an integer identifier for the memory allocator that owns the memory type.|
|If the memory type has an administrative limit on the number of simultaneous allocations, return it.|
|If the memory type has an administrative limit on the number of bytes of memory that may be simultaneously allocated for the memory type, return it.|
|If the memory type supports variable allocation sizes, return a bitmask of sizes allocated for the memory type.|
|If the memory type supports a fixed allocation size, return that size.|
|If the memory type supports a fixed allocation size, return real size of an allocation. Real size can exceed requested size due to alignment constraints or implicit padding.|
|Return the total number of bytes allocated for the memory type over its lifetime.|
|Return the total number of bytes freed for the memory type over its lifetime.|
|Return the total number of allocations for the memory type over its lifetime.|
|Return the total number of frees for the memory type over its lifetime.|
|Return the current number of bytes allocated to the memory type.|
|Return the current number of allocations for the memory type.|
|If the memory allocator supports a cache, return the number of items in the cache.|
|If the memory allocator and type permit allocation failures, return the number of allocation failures measured.|
|Return a caller-owned pointer for the memory type.|
|Set a caller-owned pointer for the memory type.|
|Return a caller-owned integer for the memory type.|
|Set a caller-owned integer for the memory type.|
|If the memory allocator supports a multi-level allocation structure, return the number of cached items in the zone. These items will be in a fully constructed state available for immediate use.|
|If the memory allocator supports a multi-level allocation structure, return the number of cached items in the keg. These items may be in a partially constructed state, and may require further processing before they can be made available for use.|
|If the memory allocator supports per-CPU statistics, return the number of bytes of memory allocated for the memory type on the CPU over its lifetime.|
|If the memory allocator supports per-CPU statistics, return the number of bytes of memory freed from the memory type on the CPU over its lifetime.|
|If the memory allocator supports per-CPU statistics, return the number of allocations for the memory type on the CPU over its lifetime.|
|If the memory allocator supports per-CPU statistics, return the number of frees for the memory type on the CPU over its lifetime.|
|If the memory allocator supports variable size memory allocation and per-CPU statistics, return the size bitmask for the memory type on the CPU.|
|Return a caller-owned per-CPU pointer for the memory type.|
|Set a caller-owned per-CPU pointer for the memory type.|
|Return a caller-owned per-CPU integer for the memory type.|
|Set a caller-owned per-CPU integer for the memory type.|
|If the memory allocator supports a per-CPU cache, return the number of free items in the per-CPU cache of the designated CPU.|
Functions returning a pointer to an object will generally return NULL on failure. memstat_mtl_alloc() will return an error value via errno, which will consist of the value ENOMEM. Functions memstat_mtl_first(), memstat_mtl_next(), and memstat_mtl_find() will return NULL when there is no entry or match in the list; however, this is not considered a failure mode and no error value is available.
Functions returning an integer success value will return 0 on success, or -1 on failure. If a failure is returned, the list error access method, memstat_mtl_geterror(), may be used to retrieve the error state. The string representation of the error may be retrieved using memstat_strerror(). Possible error values are:
|MEMSTAT_ERROR_UNDEFINED||Undefined error. Occurs if memstat_mtl_geterror() is called on a list before an error associated with the list has occurred.|
|MEMSTAT_ERROR_NOMEMORY||Insufficient memory. Occurs if library calls to malloc(3) fail, or if a system call to retrieve kernel statistics fails with ENOMEM.|
|MEMSTAT_ERROR_VERSION||Returned if the current version of libmemstat is unable to interpret the statistics data returned by the kernel due to an explicit version mismatch, or to differences in data structures that cannot be reconciled.|
|MEMSTAT_ERROR_PERMISSION||Returned if a statistics source returns errno values of EACCES or EPERM.|
|MEMSTAT_ERROR_DATAERROR||Returned if libmemstat is unable to interpret statistics data returned by the data source, even though there does not appear to be a version problem.|
|MEMSTAT_ERROR_KVM||Returned if libmemstat experiences an error while using kvm(3) interfaces to query statistics data. Use kvm_geterr(3) to retrieve the error.|
|MEMSTAT_ERROR_KVM_NOSYMBOL||Returned if libmemstat is unable to read a required symbol from the kernel being operated on.|
|Returned if libmemstat attempts to read data from a live memory image or kernel core dump and insufficient data is returned.|
Finally, functions returning data from a struct memory_type pointer are not permitted to fail, and directly return either a statistic or pointer to a string.
struct memory_type_list *mtlp; struct memory_type *mtp; uint64_t mbuf_count;
mtlp = memstat_mtl_alloc(); if (mtlp == NULL) err(-1, "memstat_mtl_alloc"); if (memstat_sysctl_uma(mtlp, 0) < 0) err(-1, "memstat_sysctl_uma"); mtp = memstat_mtl_find(mtlp, ALLOCATOR_UMA, "mbuf"); if (mtp == NULL) errx(-1, "memstat_mtl_find: mbuf not found"); mbuf_count = memstat_get_count(mtp); memstat_mtl_free(mtlp);
printf("mbufs: %llu\n", (unsigned long long)mbuf_count);
Once a memory type is present on a memory type list, it will not be removed even if the kernel no longer presents information on the type via its monitoring interfaces. In order to flush removed memory types, it is necessary to free the entire list and allocate a new one.
|LIBMEMSTAT (3)||February 11, 2014|
|Main index||Section 3||Options|
|“||… one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs.||”|
|— Robert Firth|