flexible-arrays.txt 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899
  1. Using flexible arrays in the kernel
  2. Last updated for 2.6.31
  3. Jonathan Corbet <corbet@lwn.net>
  4. Large contiguous memory allocations can be unreliable in the Linux kernel.
  5. Kernel programmers will sometimes respond to this problem by allocating
  6. pages with vmalloc(). This solution not ideal, though. On 32-bit systems,
  7. memory from vmalloc() must be mapped into a relatively small address space;
  8. it's easy to run out. On SMP systems, the page table changes required by
  9. vmalloc() allocations can require expensive cross-processor interrupts on
  10. all CPUs. And, on all systems, use of space in the vmalloc() range
  11. increases pressure on the translation lookaside buffer (TLB), reducing the
  12. performance of the system.
  13. In many cases, the need for memory from vmalloc() can be eliminated by
  14. piecing together an array from smaller parts; the flexible array library
  15. exists to make this task easier.
  16. A flexible array holds an arbitrary (within limits) number of fixed-sized
  17. objects, accessed via an integer index. Sparse arrays are handled
  18. reasonably well. Only single-page allocations are made, so memory
  19. allocation failures should be relatively rare. The down sides are that the
  20. arrays cannot be indexed directly, individual object size cannot exceed the
  21. system page size, and putting data into a flexible array requires a copy
  22. operation. It's also worth noting that flexible arrays do no internal
  23. locking at all; if concurrent access to an array is possible, then the
  24. caller must arrange for appropriate mutual exclusion.
  25. The creation of a flexible array is done with:
  26. #include <linux/flex_array.h>
  27. struct flex_array *flex_array_alloc(int element_size,
  28. unsigned int total,
  29. gfp_t flags);
  30. The individual object size is provided by element_size, while total is the
  31. maximum number of objects which can be stored in the array. The flags
  32. argument is passed directly to the internal memory allocation calls. With
  33. the current code, using flags to ask for high memory is likely to lead to
  34. notably unpleasant side effects.
  35. Storing data into a flexible array is accomplished with a call to:
  36. int flex_array_put(struct flex_array *array, unsigned int element_nr,
  37. void *src, gfp_t flags);
  38. This call will copy the data from src into the array, in the position
  39. indicated by element_nr (which must be less than the maximum specified when
  40. the array was created). If any memory allocations must be performed, flags
  41. will be used. The return value is zero on success, a negative error code
  42. otherwise.
  43. There might possibly be a need to store data into a flexible array while
  44. running in some sort of atomic context; in this situation, sleeping in the
  45. memory allocator would be a bad thing. That can be avoided by using
  46. GFP_ATOMIC for the flags value, but, often, there is a better way. The
  47. trick is to ensure that any needed memory allocations are done before
  48. entering atomic context, using:
  49. int flex_array_prealloc(struct flex_array *array, unsigned int start,
  50. unsigned int end, gfp_t flags);
  51. This function will ensure that memory for the elements indexed in the range
  52. defined by start and end has been allocated. Thereafter, a
  53. flex_array_put() call on an element in that range is guaranteed not to
  54. block.
  55. Getting data back out of the array is done with:
  56. void *flex_array_get(struct flex_array *fa, unsigned int element_nr);
  57. The return value is a pointer to the data element, or NULL if that
  58. particular element has never been allocated.
  59. Note that it is possible to get back a valid pointer for an element which
  60. has never been stored in the array. Memory for array elements is allocated
  61. one page at a time; a single allocation could provide memory for several
  62. adjacent elements. The flexible array code does not know if a specific
  63. element has been written; it only knows if the associated memory is
  64. present. So a flex_array_get() call on an element which was never stored
  65. in the array has the potential to return a pointer to random data. If the
  66. caller does not have a separate way to know which elements were actually
  67. stored, it might be wise, at least, to add GFP_ZERO to the flags argument
  68. to ensure that all elements are zeroed.
  69. There is no way to remove a single element from the array. It is possible,
  70. though, to remove all elements with a call to:
  71. void flex_array_free_parts(struct flex_array *array);
  72. This call frees all elements, but leaves the array itself in place.
  73. Freeing the entire array is done with:
  74. void flex_array_free(struct flex_array *array);
  75. As of this writing, there are no users of flexible arrays in the mainline
  76. kernel. The functions described here are also not exported to modules;
  77. that will probably be fixed when somebody comes up with a need for it.