Print this page
7831 want vmem manual pages
7832 big theory statements need a place in the manual


  24  */
  25 
  26 /*
  27  * Copyright (c) 2012, 2015 by Delphix. All rights reserved.
  28  * Copyright (c) 2012, Joyent, Inc. All rights reserved.
  29  */
  30 
  31 /*
  32  * Big Theory Statement for the virtual memory allocator.
  33  *
  34  * For a more complete description of the main ideas, see:
  35  *
  36  *      Jeff Bonwick and Jonathan Adams,
  37  *
  38  *      Magazines and vmem: Extending the Slab Allocator to Many CPUs and
  39  *      Arbitrary Resources.
  40  *
  41  *      Proceedings of the 2001 Usenix Conference.
  42  *      Available as http://www.usenix.org/event/usenix01/bonwick.html
  43  *



  44  *
  45  * 1. General Concepts
  46  * -------------------
  47  *
  48  * 1.1 Overview
  49  * ------------
  50  * We divide the kernel address space into a number of logically distinct
  51  * pieces, or *arenas*: text, data, heap, stack, and so on.  Within these
  52  * arenas we often subdivide further; for example, we use heap addresses
  53  * not only for the kernel heap (kmem_alloc() space), but also for DVMA,
  54  * bp_mapin(), /dev/kmem, and even some device mappings like the TOD chip.
  55  * The kernel address space, therefore, is most accurately described as
  56  * a tree of arenas in which each node of the tree *imports* some subset
  57  * of its parent.  The virtual memory allocator manages these arenas and
  58  * supports their natural hierarchical structure.
  59  *
  60  * 1.2 Arenas
  61  * ----------
  62  * An arena is nothing more than a set of integers.  These integers most
  63  * commonly represent virtual addresses, but in fact they can represent




  24  */
  25 
  26 /*
  27  * Copyright (c) 2012, 2015 by Delphix. All rights reserved.
  28  * Copyright (c) 2012, Joyent, Inc. All rights reserved.
  29  */
  30 
  31 /*
  32  * Big Theory Statement for the virtual memory allocator.
  33  *
  34  * For a more complete description of the main ideas, see:
  35  *
  36  *      Jeff Bonwick and Jonathan Adams,
  37  *
  38  *      Magazines and vmem: Extending the Slab Allocator to Many CPUs and
  39  *      Arbitrary Resources.
  40  *
  41  *      Proceedings of the 2001 Usenix Conference.
  42  *      Available as http://www.usenix.org/event/usenix01/bonwick.html
  43  *
  44  * Section 1, below, is also the primary contents of vmem(9).  If for some
  45  * reason you are updating this comment, you will also wish to update the
  46  * manual.
  47  *
  48  * 1. General Concepts
  49  * -------------------
  50  *
  51  * 1.1 Overview
  52  * ------------
  53  * We divide the kernel address space into a number of logically distinct
  54  * pieces, or *arenas*: text, data, heap, stack, and so on.  Within these
  55  * arenas we often subdivide further; for example, we use heap addresses
  56  * not only for the kernel heap (kmem_alloc() space), but also for DVMA,
  57  * bp_mapin(), /dev/kmem, and even some device mappings like the TOD chip.
  58  * The kernel address space, therefore, is most accurately described as
  59  * a tree of arenas in which each node of the tree *imports* some subset
  60  * of its parent.  The virtual memory allocator manages these arenas and
  61  * supports their natural hierarchical structure.
  62  *
  63  * 1.2 Arenas
  64  * ----------
  65  * An arena is nothing more than a set of integers.  These integers most
  66  * commonly represent virtual addresses, but in fact they can represent