[Linux Memory]slab Dispenser Learning Note (i)--concept

Source: Internet
Author: User

http://blog.csdn.net/vanbreaker/article/details/7664296
1, why the slab splitter is required:
Using the partner system to allocate memory can only be allocated according to the unit of the page, which will cause a lot of memory waste, a lot of memory fragmentation, such as only need to request 10 bytes, the result is assigned a page.

Differences in distribution of 2,slab allocators and partner systems
Slab allocators are managed based on objects, the same type of object is classified as a class (such as a process descriptor is a class), whenever you want to request such an object, the slab allocator allocates a unit of such size from a slab list, and when it is released, it is re-saved in the list, Instead of returning directly to the partner system. When slab allocates an object, it uses the most recently freed object memory block, so it is more likely to reside in the CPU cache
The slab allocator consists of a number of caches (dynamic linked lists) with different cache sizes (such as the length of the object managed by the cache named kmalloc-128 is 128 bytes). Linux's slab cache is divided into dedicated and generic two, the general-purpose cache through the function kmem_cache_init () to initialize, for specific objects, such as various descriptors, the cache size that holds the process descriptor is sizeof (TASK_STRUCT) , and the private cache is created through the function kmem_cache_create (). The object size of the universal slab is predefined, typically 2 recurses (need for cache alignment), Linux uses level 13, as follows: 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072. This will ensure that the memory fragment is less than 50


The concept of 3,slab

The slab allocator considers memory areas as objects (object), which consist of a set of data structures and several constructors or destructors that are used to initialize and reclaim memory, respectively. The slab allocator places objects into the tell cache, and the main memory area that contains the cache is divided into multiple slab, each slab consisting of one or more contiguous pages that contain allocated objects and idle objects.

Each slab object has a kmem_bufctl_t descriptor, and each slab object descriptor is stored behind the slab descriptor. therefore ((kmem_bufctl_t*) (slab + 1) points to the kmem_bufctl_t descriptor address of slab, and the statement ((kmem_bufctl_t*) (slab + 1) [i] is the index of the access to the I object.


Related data structures for 4,slab allocators
The data structure used to describe and manage the cache is a struct kmem_cache

[CPP]View Plaincopy
  1. struct Kmem_cache {
  2. /* 1) PER-CPU data, touched during every alloc/free */
  3. /*PER-CPU data, which records local cache information, is also used to track recently released objects, and each allocation and release is directly accessible to it */
  4. struct Array_cache *array[nr_cpus];
  5. /* 2) Cache tunables. Protected by Cache_chain_mutex */
  6. unsigned int batchcount; /* Number of objects that are transferred to or from the local cache */
  7. unsigned int limit; / * Maximum number of idle objects in local cache * /
  8. unsigned int shared;
  9. unsigned int buffer_size; /* Manage the size of objects * /
  10. U32 reciprocal_buffer_size; /*buffer_size value of the countdown * /
  11. /* 3) Touched by every alloc & free from the backend */
  12. unsigned int flags; / * Persistent ID for cache * /
  13. unsigned int num; / * The number of objects contained in a slab * /
  14. /* 4) Cache_grow/shrink */
  15. /* Order of pgs per slab (2^n) */
  16. unsigned int gfporder; / * A slab contains the logarithm of the number of consecutive page boxes * /
  17. / * Force GFP flags, e.g. GFP_DMA * /
  18. gfp_t Gfpflags; /* Assignment ID provided when interacting with the partner system */
  19. size_t colour; / * Number of colors * /
  20. unsigned int colour_off; / * The offset of the coloring * /
  21. / * If the slab descriptor is stored externally, the pointer points to the cache that stores the slab descriptor,
  22. Otherwise the null*/
  23. struct Kmem_cache *slabp_cache;
  24. unsigned int slab_size; size of/*slab admin area * /
  25. unsigned int dflags; / * Dynamic identification * /
  26. void (*ctor) (void *obj); / * constructor pointer when creating cache * /
  27. /* 5) Cache Creation/removal */
  28. Const Char *name; / * Cache name * /
  29. struct List_head next; / * Used to link the cache to the cache chain*/
  30. /* 6) Statistics */
  31. /*struct Kmem_list3 is used to organize slab*/in this cache
  32. struct KMEM_LIST3 *nodelists[max_numnodes];
  33. /*  
  34. * Do not add fields after nodelists[]
  35. */
  36. };
  37. struct KMEM_LIST3 {
  38. struct List_head slabs_partial; /*slab linked list, containing the slab descriptor for the free and allocated objects */
  39. struct List_head slabs_full; /*slab linked list, containing only non-idle slab descriptors * /
  40. struct List_head slabs_free; /*slab linked list, containing only idle slab descriptors * /
  41. unsigned long free_objects; / * Number of idle objects in cache * /
  42. unsigned int free_limit; / * Upper limit for idle objects * /
  43. unsigned int colour_next; / * Color used next slab * /
  44. spinlock_t List_lock;
  45. struct Array_cache *shared; / * Shared per node * /
  46. struct Array_cache **alien; /* On other nodes * /
  47. unsigned long next_reap; / * Updated without locking * /
  48. int free_touched; / * Updated without locking * /
  49. };
  50. The structure that describes and manages a single slab is a struct slab
  51. struct Slab {
  52. struct List_head list; / * For linking slab into the kmem_list3 list * /
  53. unsigned long colouroff; /* Coloring offset of the slab * /
  54. void *s_mem; / * Point to the first object in slab * /
  55. unsigned int inuse; / * Objects that have been allocated * /
  56. kmem_bufctl_t free; / * Subscript for next Idle object * /
  57. unsigned short nodeid; / * Node identification number * /
  58. };


The slab descriptor can be placed in the following two places
1, external slab descriptor, normal cache present
2, internal slab descriptor, in the starting position of the first page box assigned to Slab

struct Kmem_cache defines a struct Array_cache pointer array, array of elements corresponding to the number of CPUs of the system, similar to each CPU page box cache in the partner system, which is used to describe the local cache per CPU, at each array At the end of the _cache, a pointer array is used to record the idle object in the slab, and when the object is allocated, it is used in a LIFO manner, that is, allocating the object corresponding to the last index in the array to ensure that the object also resides in the cache. In fact, each allocation of memory is directly interacting with the local CPU cache, and only when its free memory is low does it introduce a subset of objects from the slab in the kmem_list to the local cache, and the idle objects in kmem_list are insufficient. Then it is necessary to introduce new pages from the partner system to create new slab, which is also the partner system
Per-CPU page box caches are similar.

[CPP]View Plaincopy
    1. struct Array_cache {
    2. unsigned int avail; /* Number of idle objects available in local cache * /
    3. unsigned int limit; /* Upper limit for idle objects * /
    4. unsigned int batchcount; /* Number of objects to be transferred and transferred at a time */
    5. unsigned int touched; / * Identifies if the local CPU has recently been used * /
    6. spinlock_t lock;
    7. void *entry[]; / * This is a pseudo-array that facilitates access to the array of pointers later used to track idle objects
    8. */
    9. };

[Linux Memory]slab Dispenser Learning Note (i)--concept

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.