| 1 | The genalloc/genpool subsystem
|
| 2 | ==============================
|
| 3 |
|
| 4 | There are a number of memory-allocation subsystems in the kernel, each
|
| 5 | aimed at a specific need. Sometimes, however, a kernel developer needs to
|
| 6 | implement a new allocator for a specific range of special-purpose memory;
|
| 7 | often that memory is located on a device somewhere. The author of the
|
| 8 | driver for that device can certainly write a little allocator to get the
|
| 9 | job done, but that is the way to fill the kernel with dozens of poorly
|
| 10 | tested allocators. Back in 2005, Jes Sorensen lifted one of those
|
| 11 | allocators from the sym53c8xx_2 driver and posted_ it as a generic module
|
| 12 | for the creation of ad hoc memory allocators. This code was merged
|
| 13 | for the 2.6.13 release; it has been modified considerably since then.
|
| 14 |
|
| 15 | .. _posted: https://lwn.net/Articles/125842/
|
| 16 |
|
| 17 | Code using this allocator should include <linux/genalloc.h>. The action
|
| 18 | begins with the creation of a pool using one of:
|
| 19 |
|
| 20 | .. kernel-doc:: lib/genalloc.c
|
| 21 | :functions: gen_pool_create
|
| 22 |
|
| 23 | .. kernel-doc:: lib/genalloc.c
|
| 24 | :functions: devm_gen_pool_create
|
| 25 |
|
| 26 | A call to gen_pool_create() will create a pool. The granularity of
|
| 27 | allocations is set with min_alloc_order; it is a log-base-2 number like
|
| 28 | those used by the page allocator, but it refers to bytes rather than pages.
|
| 29 | So, if min_alloc_order is passed as 3, then all allocations will be a
|
| 30 | multiple of eight bytes. Increasing min_alloc_order decreases the memory
|
| 31 | required to track the memory in the pool. The nid parameter specifies
|
| 32 | which NUMA node should be used for the allocation of the housekeeping
|
| 33 | structures; it can be -1 if the caller doesn't care.
|
| 34 |
|
| 35 | The "managed" interface devm_gen_pool_create() ties the pool to a
|
| 36 | specific device. Among other things, it will automatically clean up the
|
| 37 | pool when the given device is destroyed.
|
| 38 |
|
| 39 | A pool is shut down with:
|
| 40 |
|
| 41 | .. kernel-doc:: lib/genalloc.c
|
| 42 | :functions: gen_pool_destroy
|
| 43 |
|
| 44 | It's worth noting that, if there are still allocations outstanding from the
|
| 45 | given pool, this function will take the rather extreme step of invoking
|
| 46 | BUG(), crashing the entire system. You have been warned.
|
| 47 |
|
| 48 | A freshly created pool has no memory to allocate. It is fairly useless in
|
| 49 | that state, so one of the first orders of business is usually to add memory
|
| 50 | to the pool. That can be done with one of:
|
| 51 |
|
| 52 | .. kernel-doc:: include/linux/genalloc.h
|
| 53 | :functions: gen_pool_add
|
| 54 |
|
| 55 | .. kernel-doc:: lib/genalloc.c
|
| 56 | :functions: gen_pool_add_owner
|
| 57 |
|
| 58 | A call to gen_pool_add() will place the size bytes of memory
|
| 59 | starting at addr (in the kernel's virtual address space) into the given
|
| 60 | pool, once again using nid as the node ID for ancillary memory allocations.
|
| 61 | The gen_pool_add_virt() variant associates an explicit physical
|
| 62 | address with the memory; this is only necessary if the pool will be used
|
| 63 | for DMA allocations.
|
| 64 |
|
| 65 | The functions for allocating memory from the pool (and putting it back)
|
| 66 | are:
|
| 67 |
|
| 68 | .. kernel-doc:: include/linux/genalloc.h
|
| 69 | :functions: gen_pool_alloc
|
| 70 |
|
| 71 | .. kernel-doc:: lib/genalloc.c
|
| 72 | :functions: gen_pool_dma_alloc
|
| 73 |
|
| 74 | .. kernel-doc:: lib/genalloc.c
|
| 75 | :functions: gen_pool_free_owner
|
| 76 |
|
| 77 | As one would expect, gen_pool_alloc() will allocate size< bytes
|
| 78 | from the given pool. The gen_pool_dma_alloc() variant allocates
|
| 79 | memory for use with DMA operations, returning the associated physical
|
| 80 | address in the space pointed to by dma. This will only work if the memory
|
| 81 | was added with gen_pool_add_virt(). Note that this function
|
| 82 | departs from the usual genpool pattern of using unsigned long values to
|
| 83 | represent kernel addresses; it returns a void * instead.
|
| 84 |
|
| 85 | That all seems relatively simple; indeed, some developers clearly found it
|
| 86 | to be too simple. After all, the interface above provides no control over
|
| 87 | how the allocation functions choose which specific piece of memory to
|
| 88 | return. If that sort of control is needed, the following functions will be
|
| 89 | of interest:
|
| 90 |
|
| 91 | .. kernel-doc:: lib/genalloc.c
|
| 92 | :functions: gen_pool_alloc_algo_owner
|
| 93 |
|
| 94 | .. kernel-doc:: lib/genalloc.c
|
| 95 | :functions: gen_pool_set_algo
|
| 96 |
|
| 97 | Allocations with gen_pool_alloc_algo() specify an algorithm to be
|
| 98 | used to choose the memory to be allocated; the default algorithm can be set
|
| 99 | with gen_pool_set_algo(). The data value is passed to the
|
| 100 | algorithm; most ignore it, but it is occasionally needed. One can,
|
| 101 | naturally, write a special-purpose algorithm, but there is a fair set
|
| 102 | already available:
|
| 103 |
|
| 104 | - gen_pool_first_fit is a simple first-fit allocator; this is the default
|
| 105 | algorithm if none other has been specified.
|
| 106 |
|
| 107 | - gen_pool_first_fit_align forces the allocation to have a specific
|
| 108 | alignment (passed via data in a genpool_data_align structure).
|
| 109 |
|
| 110 | - gen_pool_first_fit_order_align aligns the allocation to the order of the
|
| 111 | size. A 60-byte allocation will thus be 64-byte aligned, for example.
|
| 112 |
|
| 113 | - gen_pool_best_fit, as one would expect, is a simple best-fit allocator.
|
| 114 |
|
| 115 | - gen_pool_fixed_alloc allocates at a specific offset (passed in a
|
| 116 | genpool_data_fixed structure via the data parameter) within the pool.
|
| 117 | If the indicated memory is not available the allocation fails.
|
| 118 |
|
| 119 | There is a handful of other functions, mostly for purposes like querying
|
| 120 | the space available in the pool or iterating through chunks of memory.
|
| 121 | Most users, however, should not need much beyond what has been described
|
| 122 | above. With luck, wider awareness of this module will help to prevent the
|
| 123 | writing of special-purpose memory allocators in the future.
|
| 124 |
|
| 125 | .. kernel-doc:: lib/genalloc.c
|
| 126 | :functions: gen_pool_virt_to_phys
|
| 127 |
|
| 128 | .. kernel-doc:: lib/genalloc.c
|
| 129 | :functions: gen_pool_for_each_chunk
|
| 130 |
|
| 131 | .. kernel-doc:: lib/genalloc.c
|
| 132 | :functions: gen_pool_has_addr
|
| 133 |
|
| 134 | .. kernel-doc:: lib/genalloc.c
|
| 135 | :functions: gen_pool_avail
|
| 136 |
|
| 137 | .. kernel-doc:: lib/genalloc.c
|
| 138 | :functions: gen_pool_size
|
| 139 |
|
| 140 | .. kernel-doc:: lib/genalloc.c
|
| 141 | :functions: gen_pool_get
|
| 142 |
|
| 143 | .. kernel-doc:: lib/genalloc.c
|
| 144 | :functions: of_gen_pool_get
|