xref: /illumos-gate/usr/src/uts/common/os/kmem.c (revision baf00aa8)

/*
 * CDDL HEADER START
 *
 * The contents of this file are subject to the terms of the
 * Common Development and Distribution License (the "License").
 * You may not use this file except in compliance with the License.
 *
 * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
 * or http://www.opensolaris.org/os/licensing.
 * See the License for the specific language governing permissions
 * and limitations under the License.
 *
 * When distributing Covered Code, include this CDDL HEADER in each
 * file and include the License file at usr/src/OPENSOLARIS.LICENSE.
 * If applicable, add the following below this CDDL HEADER, with the
 * fields enclosed by brackets "[]" replaced with your own identifying
 * information: Portions Copyright [yyyy] [name of copyright owner]
 *
 * CDDL HEADER END
 */
/*
 * Copyright (c) 1994, 2010, Oracle and/or its affiliates. All rights reserved.
 * Copyright (c) 2012, 2017 by Delphix. All rights reserved.
 * Copyright 2015 Nexenta Systems, Inc.  All rights reserved.
 * Copyright 2018, Joyent, Inc.
 * Copyright 2020 Oxide Computer Company
 */

/*
 * Kernel memory allocator, as described in the following two papers and a
 * statement about the consolidator:
 *
 * Jeff Bonwick,
 * The Slab Allocator: An Object-Caching Kernel Memory Allocator.
 * Proceedings of the Summer 1994 Usenix Conference.
 * Available as /shared/sac/PSARC/1994/028/materials/kmem.pdf.
 *
 * Jeff Bonwick and Jonathan Adams,
 * Magazines and vmem: Extending the Slab Allocator to Many CPUs and
 * Arbitrary Resources.
 * Proceedings of the 2001 Usenix Conference.
 * Available as /shared/sac/PSARC/2000/550/materials/vmem.pdf.
 *
 * kmem Slab Consolidator Big Theory Statement:
 *
 * 1. Motivation
 *
 * As stated in Bonwick94, slabs provide the following advantages over other
 * allocation structures in terms of memory fragmentation:
 *
 *  - Internal fragmentation (per-buffer wasted space) is minimal.
 *  - Severe external fragmentation (unused buffers on the free list) is
 *    unlikely.
 *
 * Segregating objects by size eliminates one source of external fragmentation,
 * and according to Bonwick:
 *
 *   The other reason that slabs reduce external fragmentation is that all
 *   objects in a slab are of the same type, so they have the same lifetime
 *   distribution. The resulting segregation of short-lived and long-lived
 *   objects at slab granularity reduces the likelihood of an entire page being
 *   held hostage due to a single long-lived allocation [Barrett93, Hanson90].
 *
 * While unlikely, severe external fragmentation remains possible. Clients that
 * allocate both short- and long-lived objects from the same cache cannot
 * anticipate the distribution of long-lived objects within the allocator's slab
 * implementation. Even a small percentage of long-lived objects distributed
 * randomly across many slabs can lead to a worst case scenario where the client
 * frees the majority of its objects and the system gets back almost none of the
 * slabs. Despite the client doing what it reasonably can to help the system
 * reclaim memory, the allocator cannot shake free enough slabs because of
 * lonely allocations stubbornly hanging on. Although the allocator is in a
 * position to diagnose the fragmentation, there is nothing that the allocator
 * by itself can do about it. It only takes a single allocated object to prevent
 * an entire slab from being reclaimed, and any object handed out by
 * kmem_cache_alloc() is by definition in the client's control. Conversely,
 * although the client is in a position to move a long-lived object, it has no
 * way of knowing if the object is causing fragmentation, and if so, where to
 * move it. A solution necessarily requires further cooperation between the
 * allocator and the client.
 *
 * 2. Move Callback
 *
 * The kmem slab consolidator therefore adds a move callback to the
 * allocator/client interface, improving worst-case external fragmentation in
 * kmem caches that supply a function to move objects from one memory location
 * to another. In a situation of low memory kmem attempts to consolidate all of
 * a cache's slabs at once; otherwise it works slowly to bring external
 * fragmentation within the 1/8 limit guaranteed for internal fragmentation,
 * thereby helping to avoid a low memory situation in the future.
 *
 * The callback has the following signature:
 *
 *   kmem_cbrc_t move(void *old, void *new, size_t size, void *user_arg)
 *
 * It supplies the kmem client with two addresses: the allocated object that
 * kmem wants to move and a buffer selected by kmem for the client to use as the
 * copy destination. The callback is kmem's way of saying "Please get off of
 * this buffer and use this one instead." kmem knows where it wants to move the
 * object in order to best reduce fragmentation. All the client needs to know
 * about the second argument (void *new) is that it is an allocated, constructed
 * object ready to take the contents of the old object. When the move function
 * is called, the system is likely to be low on memory, and the new object
 * spares the client from having to worry about allocating memory for the
 * requested move. The third argument supplies the size of the object, in case a
 * single move function handles multiple caches whose objects differ only in
 * size (such as zio_buf_512, zio_buf_1024, etc). Finally, the same optional
 * user argument passed to the constructor, destructor, and reclaim functions is
 * also passed to the move callback.
 *
 * 2.1 Setting the Move Callback
 *
 * The client sets the move callback after creating the cache and before
 * allocating from it:
 *
 *	object_cache = kmem_cache_create(...);
 *      kmem_cache_set_move(object_cache, object_move);
 *
 * 2.2 Move Callback Return Values
 *
 * Only the client knows about its own data and when is a good time to move it.
 * The client is cooperating with kmem to return unused memory to the system,
 * and kmem respectfully accepts this help at the client's convenience. When
 * asked to move an object, the client can respond with any of the following:
 *
 *   typedef enum kmem_cbrc {
 *           KMEM_CBRC_YES,
 *           KMEM_CBRC_NO,
 *           KMEM_CBRC_LATER,
 *           KMEM_CBRC_DONT_NEED,
 *           KMEM_CBRC_DONT_KNOW
 *   } kmem_cbrc_t;
 *
 * The client must not explicitly kmem_cache_free() either of the objects passed
 * to the callback, since kmem wants to free them directly to the slab layer
 * (bypassing the per-CPU magazine layer). The response tells kmem which of the
 * objects to free:
 *
 *       YES: (Did it) The client moved the object, so kmem frees the old one.
 *        NO: (Never) The client refused, so kmem frees the new object (the
 *            unused copy destination). kmem also marks the slab of the old
 *            object so as not to bother the client with further callbacks for
 *            that object as long as the slab remains on the partial slab list.
 *            (The system won't be getting the slab back as long as the
 *            immovable object holds it hostage, so there's no point in moving
 *            any of its objects.)
 *     LATER: The client is using the object and cannot move it now, so kmem
 *            frees the new object (the unused copy destination). kmem still
 *            attempts to move other objects off the slab, since it expects to
 *            succeed in clearing the slab in a later callback. The client
 *            should use LATER instead of NO if the object is likely to become
 *            movable very soon.
 * DONT_NEED: The client no longer needs the object, so kmem frees the old along
 *            with the new object (the unused copy destination). This response
 *            is the client's opportunity to be a model citizen and give back as
 *            much as it can.
 * DONT_KNOW: The client does not know about the object because
 *            a) the client has just allocated the object and not yet put it
 *               wherever it expects to find known objects
 *            b) the client has removed the object from wherever it expects to
 *               find known objects and is about to free it, or
 *            c) the client has freed the object.
 *            In all these cases (a, b, and c) kmem frees the new object (the
 *            unused copy destination).  In the first case, the object is in
 *            use and the correct action is that for LATER; in the latter two
 *            cases, we know that the object is either freed or about to be
 *            freed, in which case it is either already in a magazine or about
 *            to be in one.  In these cases, we know that the object will either
 *            be reallocated and reused, or it will end up in a full magazine
 *            that will be reaped (thereby liberating the slab).  Because it
 *            is prohibitively expensive to differentiate these cases, and
 *            because the defrag code is executed when we're low on memory
 *            (thereby biasing the system to reclaim full magazines) we treat
 *            all DONT_KNOW cases as LATER and rely on cache reaping to
 *            generally clean up full magazines.  While we take the same action
 *            for these cases, we maintain their semantic distinction:  if
 *            defragmentation is not occurring, it is useful to know if this
 *            is due to objects in use (LATER) or objects in an unknown state
 *            of transition (DONT_KNOW).
 *
 * 2.3 Object States
 *
 * Neither kmem nor the client can be assumed to know the object's whereabouts
 * at the time of the callback. An object belonging to a kmem cache may be in
 * any of the following states:
 *
 * 1. Uninitialized on the slab
 * 2. Allocated from the slab but not constructed (still uninitialized)
 * 3. Allocated from the slab, constructed, but not yet ready for business
 *    (not in a valid state for the move callback)
 * 4. In use (valid and known to the client)
 * 5. About to be freed (no longer in a valid state for the move callback)
 * 6. Freed to a magazine (still constructed)
 * 7. Allocated from a magazine, not yet ready for business (not in a valid
 *    state for the move callback), and about to return to state #4
 * 8. Deconstructed on a magazine that is about to be freed
 * 9. Freed to the slab
 *
 * Since the move callback may be called at any time while the object is in any
 * of the above states (except state #1), the client needs a safe way to
 * determine whether or not it knows about the object. Specifically, the client
 * needs to know whether or not the object is in state #4, the only state in
 * which a move is valid. If the object is in any other state, the client should
 * immediately return KMEM_CBRC_DONT_KNOW, since it is unsafe to access any of
 * the object's fields.
 *
 * Note that although an object may be in state #4 when kmem initiates the move
 * request, the object may no longer be in that state by the time kmem actually
 * calls the move function. Not only does the client free objects
 * asynchronously, kmem itself puts move requests on a queue where thay are
 * pending until kmem processes them from another context. Also, objects freed
 * to a magazine appear allocated from the point of view of the slab layer, so
 * kmem may even initiate requests for objects in a state other than state #4.
 *
 * 2.3.1 Magazine Layer
 *
 * An important insight revealed by the states listed above is that the magazine
 * layer is populated only by kmem_cache_free(). Magazines of constructed
 * objects are never populated directly from the slab layer (which contains raw,
 * unconstructed objects). Whenever an allocation request cannot be satisfied
 * from the magazine layer, the magazines are bypassed and the request is
 * satisfied from the slab layer (creating a new slab if necessary). kmem calls
 * the object constructor only when allocating from the slab layer, and only in
 * response to kmem_cache_alloc() or to prepare the destination buffer passed in
 * the move callback. kmem does not preconstruct objects in anticipation of
 * kmem_cache_alloc().
 *
 * 2.3.2 Object Constructor and Destructor
 *
 * If the client supplies a destructor, it must be valid to call the destructor
 * on a newly created object (immediately after the constructor).
 *
 * 2.4 Recognizing Known Objects
 *
 * There is a simple test to determine safely whether or not the client knows
 * about a given object in the move callback. It relies on the fact that kmem
 * guarantees that the object of the move callback has only been touched by the
 * client itself or else by kmem. kmem does this by ensuring that none of the
 * cache's slabs are freed to the virtual memory (VM) subsystem while a move
 * callback is pending. When the last object on a slab is freed, if there is a
 * pending move, kmem puts the slab on a per-cache dead list and defers freeing
 * slabs on that list until all pending callbacks are completed. That way,
 * clients can be certain that the object of a move callback is in one of the
 * states listed above, making it possible to distinguish known objects (in
 * state #4) using the two low order bits of any pointer member (with the
 * exception of 'char *' or 'short *' which may not be 4-byte aligned on some
 * platforms).
 *
 * The test works as long as the client always transitions objects from state #4
 * (known, in use) to state #5 (about to be freed, invalid) by setting the low
 * order bit of the client-designated pointer member. Since kmem only writes
 * invalid memory patterns, such as 0xbaddcafe to uninitialized memory and
 * 0xdeadbeef to freed memory, any scribbling on the object done by kmem is
 * guaranteed to set at least one of the two low order bits. Therefore, given an
 * object with a back pointer to a 'container_t *o_container', the client can
 * test
 *
 *      container_t *container = object->o_container;
 *      if ((uintptr_t)container & 0x3) {
 *              return (KMEM_CBRC_DONT_KNOW);
 *      }
 *
 * Typically, an object will have a pointer to some structure with a list or
 * hash where objects from the cache are kept while in use. Assuming that the
 * client has some way of knowing that the container structure is valid and will
 * not go away during the move, and assuming that the structure includes a lock
 * to protect whatever collection is used, then the client would continue as
 * follows:
 *
 *	// Ensure that the container structure does not go away.
 *      if (container_hold(container) == 0) {
 *              return (KMEM_CBRC_DONT_KNOW);
 *      }
 *      mutex_enter(&container->c_objects_lock);
 *      if (container != object->o_container) {
 *              mutex_exit(&container->c_objects_lock);
 *              container_rele(container);
 *              return (KMEM_CBRC_DONT_KNOW);
 *      }
 *
 * At this point the client knows that the object cannot be freed as long as
 * c_objects_lock is held. Note that after acquiring the lock, the client must
 * recheck the o_container pointer in case the object was removed just before
 * acquiring the lock.
 *
 * When the client is about to free an object, it must first remove that object
 * from the list, hash, or other structure where it is kept. At that time, to
 * mark the object so it can be distinguished from the remaining, known objects,
 * the client sets the designated low order bit:
 *
 *      mutex_enter(&container->c_objects_lock);
 *      object->o_container = (void *)((uintptr_t)object->o_container | 0x1);
 *      list_remove(&container->c_objects, object);
 *      mutex_exit(&container->c_objects_lock);
 *
 * In the common case, the object is freed to the magazine layer, where it may
 * be reused on a subsequent allocation without the overhead of calling the
 * constructor. While in the magazine it appears allocated from the point of
 * view of the slab layer, making it a candidate for the move callback. Most
 * objects unrecognized by the client in the move callback fall into this
 * category and are cheaply distinguished from known objects by the test
 * described earlier. Because searching magazines is prohibitively expensive
 * for kmem, clients that do not mark freed objects (and therefore return
 * KMEM_CBRC_DONT_KNOW for large numbers of objects) may find defragmentation
 * efficacy reduced.
 *
 * Invalidating the designated pointer member before freeing the object marks
 * the object to be avoided in the callback, and conversely, assigning a valid
 * value to the designated pointer member after allocating the object makes the
 * object fair game for the callback:
 *
 *      ... allocate object ...
 *      ... set any initial state not set by the constructor ...
 *
 *      mutex_enter(&container->c_objects_lock);
 *      list_insert_tail(&container->c_objects, object);
 *      membar_producer();
 *      object->o_container = container;
 *      mutex_exit(&container->c_objects_lock);
 *
 * Note that everything else must be valid before setting o_container makes the
 * object fair game for the move callback. The membar_producer() call ensures
 * that all the object's state is written to memory before setting the pointer
 * that transitions the object from state #3 or #7 (allocated, constructed, not
 * yet in use) to state #4 (in use, valid). That's important because the move
 * function has to check the validity of the pointer before it can safely
 * acquire the lock protecting the collection where it expects to find known
 * objects.
 *
 * This method of distinguishing known objects observes the usual symmetry:
 * invalidating the designated pointer is the first thing the client does before
 * freeing the object, and setting the designated pointer is the last thing the
 * client does after allocating the object. Of course, the client is not
 * required to use this method. Fundamentally, how the client recognizes known
 * objects is completely up to the client, but this method is recommended as an
 * efficient and safe way to take advantage of the guarantees made by kmem. If
 * the entire object is arbitrary data without any markable bits from a suitable
 * pointer member, then the client must find some other method, such as
 * searching a hash table of known objects.
 *
 * 2.5 Preventing Objects From Moving
 *
 * Besides a way to distinguish known objects, the other thing that the client
 * needs is a strategy to ensure that an object will not move while the client
 * is actively using it. The details of satisfying this requirement tend to be
 * highly cache-specific. It might seem that the same rules that let a client
 * remove an object safely should also decide when an object can be moved
 * safely. However, any object state that makes a removal attempt invalid is
 * likely to be long-lasting for objects that the client does not expect to
 * remove. kmem knows nothing about the object state and is equally likely (from
 * the client's point of view) to request a move for any object in the cache,
 * whether prepared for removal or not. Even a low percentage of objects stuck
 * in place by unremovability will defeat the consolidator if the stuck objects
 * are the same long-lived allocations likely to hold slabs hostage.
 * Fundamentally, the consolidator is not aimed at common cases. Severe external
 * fragmentation is a worst case scenario manifested as sparsely allocated
 * slabs, by definition a low percentage of the cache's objects. When deciding
 * what makes an object movable, keep in mind the goal of the consolidator: to
 * bring worst-case external fragmentation within the limits guaranteed for
 * internal fragmentation. Removability is a poor criterion if it is likely to
 * exclude more than an insignificant percentage of objects for long periods of
 * time.
 *
 * A tricky general solution exists, and it has the advantage of letting you
 * move any object at almost any moment, practically eliminating the likelihood
 * that an object can hold a slab hostage. However, if there is a cache-specific
 * way to ensure that an object is not actively in use in the vast majority of
 * cases, a simpler solution that leverages this cache-specific knowledge is
 * preferred.
 *
 * 2.5.1 Cache-Specific Solution
 *
 * As an example of a cache-specific solution, the ZFS znode cache takes
 * advantage of the fact that the vast majority of znodes are only being
 * referenced from the DNLC. (A typical case might be a few hundred in active
 * use and a hundred thousand in the DNLC.) In the move callback, after the ZFS
 * client has established that it recognizes the znode and can access its fields
 * safely (using the method described earlier), it then tests whether the znode
 * is referenced by anything other than the DNLC. If so, it assumes that the
 * znode may be in active use and is unsafe to move, so it drops its locks and
 * returns KMEM_CBRC_LATER. The advantage of this strategy is that everywhere
 * else znodes are used, no change is needed to protect against the possibility
 * of the znode moving. The disadvantage is that it remains possible for an
 * application to hold a znode slab hostage with an open file descriptor.
 * However, this case ought to be rare and the consolidator has a way to deal
 * with it: If the client responds KMEM_CBRC_LATER repeatedly for the same
 * object, kmem eventually stops believing it and treats the slab as if the
 * client had responded KMEM_CBRC_NO. Having marked the hostage slab, kmem can
 * then focus on getting it off of the partial slab list by allocating rather
 * than freeing all of its objects. (Either way of getting a slab off the
 * free list reduces fragmentation.)
 *
 * 2.5.2 General Solution
 *
 * The general solution, on the other hand, requires an explicit hold everywhere
 * the object is used to prevent it from moving. To keep the client locking
 * strategy as uncomplicated as possible, kmem guarantees the simplifying
 * assumption that move callbacks are sequential, even across multiple caches.
 * Internally, a global queue processed by a single thread supports all caches
 * implementing the callback function. No matter how many caches supply a move
 * function, the consolidator never moves more than one object at a time, so the
 * client does not have to worry about tricky lock ordering involving several
 * related objects from different kmem caches.
 *
 * The general solution implements the explicit hold as a read-write lock, which
 * allows multiple readers to access an object from the cache simultaneously
 * while a single writer is excluded from moving it. A single rwlock for the
 * entire cache would lock out all threads from using any of the cache's objects
 * even though only a single object is being moved, so to reduce contention,
 * the client can fan out the single rwlock into an array of rwlocks hashed by
 * the object address, making it probable that moving one object will not
 * prevent other threads from using a different object. The rwlock cannot be a
 * member of the object itself, because the possibility of the object moving
 * makes it unsafe to access any of the object's fields until the lock is
 * acquired.
 *
 * Assuming a small, fixed number of locks, it's possible that multiple objects
 * will hash to the same lock. A thread that needs to use multiple objects in
 * the same function may acquire the same lock multiple times. Since rwlocks are
 * reentrant for readers, and since there is never more than a single writer at
 * a time (assuming that the client acquires the lock as a writer only when
 * moving an object inside the callback), there would seem to be no problem.
 * However, a client locking multiple objects in the same function must handle
 * one case of potential deadlock: Assume that thread A needs to prevent both
 * object 1 and object 2 from moving, and thread B, the callback, meanwhile
 * tries to move object 3. It's possible, if objects 1, 2, and 3 all hash to the
 * same lock, that thread A will acquire the lock for object 1 as a reader
 * before thread B sets the lock's write-wanted bit, preventing thread A from
 * reacquiring the lock for object 2 as a reader. Unable to make forward
 * progress, thread A will never release the lock for object 1, resulting in
 * deadlock.
 *
 * There are two ways of avoiding the deadlock just described. The first is to
 * use rw_tryenter() rather than rw_enter() in the callback function when
 * attempting to acquire the lock as a writer. If tryenter discovers that the
 * same object (or another object hashed to the same lock) is already in use, it
 * aborts the callback and returns KMEM_CBRC_LATER. The second way is to use
 * rprwlock_t (declared in common/fs/zfs/sys/rprwlock.h) instead of rwlock_t,
 * since it allows a thread to acquire the lock as a reader in spite of a
 * waiting writer. This second approach insists on moving the object now, no
 * matter how many readers the move function must wait for in order to do so,
 * and could delay the completion of the callback indefinitely (blocking
 * callbacks to other clients). In practice, a less insistent callback using
 * rw_tryenter() returns KMEM_CBRC_LATER infrequently enough that there seems
 * little reason to use anything else.
 *
 * Avoiding deadlock is not the only problem that an implementation using an
 * explicit hold needs to solve. Locking the object in the first place (to
 * prevent it from moving) remains a problem, since the object could move
 * between the time you obtain a pointer to the object and the time you acquire
 * the rwlock hashed to that pointer value. Therefore the client needs to
 * recheck the value of the pointer after acquiring the lock, drop the lock if
 * the value has changed, and try again. This requires a level of indirection:
 * something that points to the object rather than the object itself, that the
 * client can access safely while attempting to acquire the lock. (The object
 * itself cannot be referenced safely because it can move at any time.)
 * The following lock-acquisition function takes whatever is safe to reference
 * (arg), follows its pointer to the object (using function f), and tries as
 * often as necessary to acquire the hashed lock and verify that the object
 * still has not moved:
 *
 *      object_t *
 *      object_hold(object_f f, void *arg)
 *      {
 *              object_t *op;
 *
 *              op = f(arg);
 *              if (op == NULL) {
 *                      return (NULL);
 *              }
 *
 *              rw_enter(OBJECT_RWLOCK(op), RW_READER);
 *              while (op != f(arg)) {
 *                      rw_exit(OBJECT_RWLOCK(op));
 *                      op = f(arg);
 *                      if (op == NULL) {
 *                              break;
 *                      }
 *                      rw_enter(OBJECT_RWLOCK(op), RW_READER);
 *              }
 *
 *              return (op);
 *      }
 *
 * The OBJECT_RWLOCK macro hashes the object address to obtain the rwlock. The
 * lock reacquisition loop, while necessary, almost never executes. The function
 * pointer f (used to obtain the object pointer from arg) has the following type
 * definition:
 *
 *      typedef object_t *(*object_f)(void *arg);
 *
 * An object_f implementation is likely to be as simple as accessing a structure
 * member:
 *
 *      object_t *
 *      s_object(void *arg)
 *      {
 *              something_t *sp = arg;
 *              return (sp->s_object);
 *      }
 *
 * The flexibility of a function pointer allows the path to the object to be
 * arbitrarily complex and also supports the notion that depending on where you
 * are using the object, you may need to get it from someplace different.
 *
 * The function that releases the explicit hold is simpler because it does not
 * have to worry about the object moving:
 *
 *      void
 *      object_rele(object_t *op)
 *      {
 *              rw_exit(OBJECT_RWLOCK(op));
 *      }
 *
 * The caller is spared these details so that obtaining and releasing an
 * explicit hold feels like a simple mutex_enter()/mutex_exit() pair. The caller
 * of object_hold() only needs to know that the returned object pointer is valid
 * if not NULL and that the object will not move until released.
 *
 * Although object_hold() prevents an object from moving, it does not prevent it
 * from being freed. The caller must take measures before calling object_hold()
 * (afterwards is too late) to ensure that the held object cannot be freed. The
 * caller must do so without accessing the unsafe object reference, so any lock
 * or reference count used to ensure the continued existence of the object must
 * live outside the object itself.
 *
 * Obtaining a new object is a special case where an explicit hold is impossible
 * for the caller. Any function that returns a newly allocated object (either as
 * a return value, or as an in-out paramter) must return it already held; after
 * the caller gets it is too late, since the object cannot be safely accessed
 * without the level of indirection described earlier. The following
 * object_alloc() example uses the same code shown earlier to transition a new
 * object into the state of being recognized (by the client) as a known object.
 * The function must acquire the hold (rw_enter) before that state transition
 * makes the object movable:
 *
 *      static object_t *
 *      object_alloc(container_t *container)
 *      {
 *              object_t *object = kmem_cache_alloc(object_cache, 0);
 *              ... set any initial state not set by the constructor ...
 *              rw_enter(OBJECT_RWLOCK(object), RW_READER);
 *              mutex_enter(&container->c_objects_lock);
 *              list_insert_tail(&container->c_objects, object);
 *              membar_producer();
 *              object->o_container = container;
 *              mutex_exit(&container->c_objects_lock);
 *              return (object);
 *      }
 *
 * Functions that implicitly acquire an object hold (any function that calls
 * object_alloc() to supply an object for the caller) need to be carefully noted
 * so that the matching object_rele() is not neglected. Otherwise, leaked holds
 * prevent all objects hashed to the affected rwlocks from ever being moved.
 *
 * The pointer to a held object can be hashed to the holding rwlock even after
 * the object has been freed. Although it is possible to release the hold
 * after freeing the object, you may decide to release the hold implicitly in
 * whatever function frees the object, so as to release the hold as soon as
 * possible, and for the sake of symmetry with the function that implicitly
 * acquires the hold when it allocates the object. Here, object_free() releases
 * the hold acquired by object_alloc(). Its implicit object_rele() forms a
 * matching pair with object_hold():
 *
 *      void
 *      object_free(object_t *object)
 *      {
 *              container_t *container;
 *
 *              ASSERT(object_held(object));
 *              container = object->o_container;
 *              mutex_enter(&container->c_objects_lock);
 *              object->o_container =
 *                  (void *)((uintptr_t)object->o_container | 0x1);
 *              list_remove(&container->c_objects, object);
 *              mutex_exit(&container->c_objects_lock);
 *              object_rele(object);
 *              kmem_cache_free(object_cache, object);
 *      }
 *
 * Note that object_free() cannot safely accept an object pointer as an argument
 * unless the object is already held. Any function that calls object_free()
 * needs to be carefully noted since it similarly forms a matching pair with
 * object_hold().
 *
 * To complete the picture, the following callback function implements the
 * general solution by moving objects only if they are currently unheld:
 *
 *      static kmem_cbrc_t
 *      object_move(void *buf, void *newbuf, size_t size, void *arg)
 *      {
 *              object_t *op = buf, *np = newbuf;
 *              container_t *container;
 *
 *              container = op->o_container;
 *              if ((uintptr_t)container & 0x3) {
 *                      return (KMEM_CBRC_DONT_KNOW);
 *              }
 *
 *	        // Ensure that the container structure does not go away.
 *              if (container_hold(container) == 0) {
 *                      return (KMEM_CBRC_DONT_KNOW);
 *              }
 *
 *              mutex_enter(&container->c_objects_lock);
 *              if (container != op->o_container) {
 *                      mutex_exit(&container->c_objects_lock);
 *                      container_rele(container);
 *                      return (KMEM_CBRC_DONT_KNOW);
 *              }
 *
 *              if (rw_tryenter(OBJECT_RWLOCK(op), RW_WRITER) == 0) {
 *                      mutex_exit(&container->c_objects_lock);
 *                      container_rele(container);
 *                      return (KMEM_CBRC_LATER);
 *              }
 *
 *              object_move_impl(op, np); // critical section
 *              rw_exit(OBJECT_RWLOCK(op));
 *
 *              op->o_container = (void *)((uintptr_t)op->o_container | 0x1);
 *              list_link_replace(&op->o_link_node, &np->o_link_node);
 *              mutex_exit(&container->c_objects_lock);
 *              container_rele(container);
 *              return (KMEM_CBRC_YES);
 *      }
 *
 * Note that object_move() must invalidate the designated o_container pointer of
 * the old object in the same way that object_free() does, since kmem will free
 * the object in response to the KMEM_CBRC_YES return value.
 *
 * The lock order in object_move() differs from object_alloc(), which locks
 * OBJECT_RWLOCK first and &container->c_objects_lock second, but as long as the
 * callback uses rw_tryenter() (preventing the deadlock described earlier), it's
 * not a problem. Holding the lock on the object list in the example above
 * through the entire callback not only prevents the object from going away, it
 * also allows you to lock the list elsewhere and know that none of its elements
 * will move during iteration.
 *
 * Adding an explicit hold everywhere an object from the cache is used is tricky
 * and involves much more change to client code than a cache-specific solution
 * that leverages existing state to decide whether or not an object is
 * movable. However, this approach has the advantage that no object remains
 * immovable for any significant length of time, making it extremely unlikely
 * that long-lived allocations can continue holding slabs hostage; and it works
 * for any cache.
 *
 * 3. Consolidator Implementation
 *
 * Once the client supplies a move function that a) recognizes known objects and
 * b) avoids moving objects that are actively in use, the remaining work is up
 * to the consolidator to decide which objects to move and when to issue
 * callbacks.
 *
 * The consolidator relies on the fact that a cache's slabs are ordered by
 * usage. Each slab has a fixed number of objects. Depending on the slab's
 * "color" (the offset of the first object from the beginning of the slab;
 * offsets are staggered to mitigate false sharing of cache lines) it is either
 * the maximum number of objects per slab determined at cache creation time or
 * else the number closest to the maximum that fits within the space remaining
 * after the initial offset. A completely allocated slab may contribute some
 * internal fragmentation (per-slab overhead) but no external fragmentation, so
 * it is of no interest to the consolidator. At the other extreme, slabs whose
 * objects have all been freed to the slab are released to the virtual memory
 * (VM) subsystem (objects freed to magazines are still allocated as far as the
 * slab is concerned). External fragmentation exists when there are slabs
 * somewhere between these extremes. A partial slab has at least one but not all
 * of its objects allocated. The more partial slabs, and the fewer allocated
 * objects on each of them, the higher the fragmentation. Hence the
 * consolidator's overall strategy is to reduce the number of partial slabs by
 * moving allocated objects from the least allocated slabs to the most allocated
 * slabs.
 *
 * Partial slabs are kept in an AVL tree ordered by usage. Completely allocated
 * slabs are kept separately in an unordered list. Since the majority of slabs
 * tend to be completely allocated (a typical unfragmented cache may have
 * thousands of complete slabs and only a single partial slab), separating
 * complete slabs improves the efficiency of partial slab ordering, since the
 * complete slabs do not affect the depth or balance of the AVL tree. This
 * ordered sequence of partial slabs acts as a "free list" supplying objects for
 * allocation requests.
 *
 * Objects are always allocated from the first partial slab in the free list,
 * where the allocation is most likely to eliminate a partial slab (by
 * completely allocating it). Conversely, when a single object from a completely
 * allocated slab is freed to the slab, that slab is added to the front of the
 * free list. Since most free list activity involves highly allocated slabs
 * coming and going at the front of the list, slabs tend naturally toward the
 * ideal order: highly allocated at the front, sparsely allocated at the back.
 * Slabs with few allocated objects are likely to become completely free if they
 * keep a safe distance away from the front of the free list. Slab misorders
 * interfere with the natural tendency of slabs to become completely free or
 * completely allocated. For example, a slab with a single allocated object
 * needs only a single free to escape the cache; its natural desire is
 * frustrated when it finds itself at the front of the list where a second
 * allocation happens just before the free could have released it. Another slab
 * with all but one object allocated might have supplied the buffer instead, so
 * that both (as opposed to neither) of the slabs would have been taken off the
 * free list.
 *
 * Although slabs tend naturally toward the ideal order, misorders allowed by a
 * simple list implementation defeat the consolidator's strategy of merging
 * least- and most-allocated slabs. Without an AVL tree to guarantee order, kmem
 * needs another way to fix misorders to optimize its callback strategy. One
 * approach is to periodically scan a limited number of slabs, advancing a
 * marker to hold the current scan position, and to move extreme misorders to
 * the front or back of the free list and to the front or back of the current
 * scan range. By making consecutive scan ranges overlap by one slab, the least
 * allocated slab in the current range can be carried along from the end of one
 * scan to the start of the next.
 *
 * Maintaining partial slabs in an AVL tree relieves kmem of this additional
 * task, however. Since most of the cache's activity is in the magazine layer,
 * and allocations from the slab layer represent only a startup cost, the
 * overhead of maintaining a balanced tree is not a significant concern compared
 * to the opportunity of reducing complexity by eliminating the partial slab
 * scanner just described. The overhead of an AVL tree is minimized by
 * maintaining only partial slabs in the tree and keeping completely allocated
 * slabs separately in a list. To avoid increasing the size of the slab
 * structure the AVL linkage pointers are reused for the slab's list linkage,
 * since the slab will always be either partial or complete, never stored both
 * ways at the same time. To further minimize the overhead of the AVL tree the
 * compare function that orders partial slabs by usage divides the range of
 * allocated object counts into bins such that counts within the same bin are
 * considered equal. Binning partial slabs makes it less likely that allocating
 * or freeing a single object will change the slab's order, requiring a tree
 * reinsertion (an avl_remove() followed by an avl_add(), both potentially
 * requiring some rebalancing of the tree). Allocation counts closest to
 * completely free and completely allocated are left unbinned (finely sorted) to
 * better support the consolidator's strategy of merging slabs at either
 * extreme.
 *
 * 3.1 Assessing Fragmentation and Selecting Candidate Slabs
 *
 * The consolidator piggybacks on the kmem maintenance thread and is called on
 * the same interval as kmem_cache_update(), once per cache every fifteen
 * seconds. kmem maintains a running count of unallocated objects in the slab
 * layer (cache_bufslab). The consolidator checks whether that number exceeds
 * 12.5% (1/8) of the total objects in the cache (cache_buftotal), and whether
 * there is a significant number of slabs in the cache (arbitrarily a minimum
 * 101 total slabs). Unused objects that have fallen out of the magazine layer's
 * working set are included in the assessment, and magazines in the depot are
 * reaped if those objects would lift cache_bufslab above the fragmentation
 * threshold. Once the consolidator decides that a cache is fragmented, it looks
 * for a candidate slab to reclaim, starting at the end of the partial slab free
 * list and scanning backwards. At first the consolidator is choosy: only a slab
 * with fewer than 12.5% (1/8) of its objects allocated qualifies (or else a
 * single allocated object, regardless of percentage). If there is difficulty
 * finding a candidate slab, kmem raises the allocation threshold incrementally,
 * up to a maximum 87.5% (7/8), so that eventually the consolidator will reduce
 * external fragmentation (unused objects on the free list) below 12.5% (1/8),
 * even in the worst case of every slab in the cache being almost 7/8 allocated.
 * The threshold can also be lowered incrementally when candidate slabs are easy
 * to find, and the threshold is reset to the minimum 1/8 as soon as the cache
 * is no longer fragmented.
 *
 * 3.2 Generating Callbacks
 *
 * Once an eligible slab is chosen, a callback is generated for every allocated
 * object on the slab, in the hope that the client will move everything off the
 * slab and make it reclaimable. Objects selected as move destinations are
 * chosen from slabs at the front of the free list. Assuming slabs in the ideal
 * order (most allocated at the front, least allocated at the back) and a
 * cooperative client, the consolidator will succeed in removing slabs from both
 * ends of the free list, completely allocating on the one hand and completely
 * freeing on the other. Objects selected as move destinations are allocated in
 * the kmem maintenance thread where move requests are enqueued. A separate
 * callback thread removes pending callbacks from the queue and calls the
 * client. The separate thread ensures that client code (the move function) does
 * not interfere with internal kmem maintenance tasks. A map of pending
 * callbacks keyed by object address (the object to be moved) is checked to
 * ensure that duplicate callbacks are not generated for the same object.
 * Allocating the move destination (the object to move to) prevents subsequent
 * callbacks from selecting the same destination as an earlier pending callback.
 *
 * Move requests can also be generated by kmem_cache_reap() when the system is
 * desperate for memory and by kmem_cache_move_notify(), called by the client to
 * notify kmem that a move refused earlier with KMEM_CBRC_LATER is now possible.
 * The map of pending callbacks is protected by the same lock that protects the
 * slab layer.
 *
 * When the system is desperate for memory, kmem does not bother to determine
 * whether or not the cache exceeds the fragmentation threshold, but tries to
 * consolidate as many slabs as possible. Normally, the consolidator chews
 * slowly, one sparsely allocated slab at a time during each maintenance
 * interval that the cache is fragmented. When desperate, the consolidator
 * starts at the last partial slab and enqueues callbacks for every allocated
 * object on every partial slab, working backwards until it reaches the first
 * partial slab. The first partial slab, meanwhile, advances in pace with the
 * consolidator as allocations to supply move destinations for the enqueued
 * callbacks use up the highly allocated slabs at the front of the free list.
 * Ideally, the overgrown free list collapses like an accordion, starting at
 * both ends and ending at the center with a single partial slab.
 *
 * 3.3 Client Responses
 *
 * When the client returns KMEM_CBRC_NO in response to the move callback, kmem
 * marks the slab that supplied the stuck object non-reclaimable and moves it to
 * front of the free list. The slab remains marked as long as it remains on the
 * free list, and it appears more allocated to the partial slab compare function
 * than any unmarked slab, no matter how many of its objects are allocated.
 * Since even one immovable object ties up the entire slab, the goal is to
 * completely allocate any slab that cannot be completely freed. kmem does not
 * bother generating callbacks to move objects from a marked slab unless the
 * system is desperate.
 *
 * When the client responds KMEM_CBRC_LATER, kmem increments a count for the
 * slab. If the client responds LATER too many times, kmem disbelieves and
 * treats the response as a NO. The count is cleared when the slab is taken off
 * the partial slab list or when the client moves one of the slab's objects.
 *
 * 4. Observability
 *
 * A kmem cache's external fragmentation is best observed with 'mdb -k' using
 * the ::kmem_slabs dcmd. For a complete description of the command, enter
 * '::help kmem_slabs' at the mdb prompt.
 */

#include <sys/kmem_impl.h>
#include <sys/vmem_impl.h>
#include <sys/param.h>
#include <sys/sysmacros.h>
#include <sys/vm.h>
#include <sys/proc.h>
#include <sys/tuneable.h>
#include <sys/systm.h>
#include <sys/cmn_err.h>
#include <sys/debug.h>
#include <sys/sdt.h>
#include <sys/mutex.h>
#include <sys/bitmap.h>
#include <sys/atomic.h>
#include <sys/kobj.h>
#include <sys/disp.h>
#include <vm/seg_kmem.h>
#include <sys/log.h>
#include <sys/callb.h>
#include <sys/taskq.h>
#include <sys/modctl.h>
#include <sys/reboot.h>
#include <sys/id32.h>
#include <sys/zone.h>
#include <sys/netstack.h>
#ifdef	DEBUG
#include <sys/random.h>
#endif

extern void streams_msg_init(void);
extern int segkp_fromheap;
extern void segkp_cache_free(void);
extern int callout_init_done;

struct kmem_cache_kstat {
	kstat_named_t	kmc_buf_size;
	kstat_named_t	kmc_align;
	kstat_named_t	kmc_chunk_size;
	kstat_named_t	kmc_slab_size;
	kstat_named_t	kmc_alloc;
	kstat_named_t	kmc_alloc_fail;
	kstat_named_t	kmc_free;
	kstat_named_t	kmc_depot_alloc;
	kstat_named_t	kmc_depot_free;
	kstat_named_t	kmc_depot_contention;
	kstat_named_t	kmc_slab_alloc;
	kstat_named_t	kmc_slab_free;
	kstat_named_t	kmc_buf_constructed;
	kstat_named_t	kmc_buf_avail;
	kstat_named_t	kmc_buf_inuse;
	kstat_named_t	kmc_buf_total;
	kstat_named_t	kmc_buf_max;
	kstat_named_t	kmc_slab_create;
	kstat_named_t	kmc_slab_destroy;
	kstat_named_t	kmc_vmem_source;
	kstat_named_t	kmc_hash_size;
	kstat_named_t	kmc_hash_lookup_depth;
	kstat_named_t	kmc_hash_rescale;
	kstat_named_t	kmc_full_magazines;
	kstat_named_t	kmc_empty_magazines;
	kstat_named_t	kmc_magazine_size;
	kstat_named_t	kmc_reap; /* number of kmem_cache_reap() calls */
	kstat_named_t	kmc_defrag; /* attempts to defrag all partial slabs */
	kstat_named_t	kmc_scan; /* attempts to defrag one partial slab */
	kstat_named_t	kmc_move_callbacks; /* sum of yes, no, later, dn, dk */
	kstat_named_t	kmc_move_yes;
	kstat_named_t	kmc_move_no;
	kstat_named_t	kmc_move_later;
	kstat_named_t	kmc_move_dont_need;
	kstat_named_t	kmc_move_dont_know; /* obj unrecognized by client ... */
	kstat_named_t	kmc_move_hunt_found; /* ... but found in mag layer */
	kstat_named_t	kmc_move_slabs_freed; /* slabs freed by consolidator */
	kstat_named_t	kmc_move_reclaimable; /* buffers, if consolidator ran */
} kmem_cache_kstat = {
	{ "buf_size",		KSTAT_DATA_UINT64 },
	{ "align",		KSTAT_DATA_UINT64 },
	{ "chunk_size",		KSTAT_DATA_UINT64 },
	{ "slab_size",		KSTAT_DATA_UINT64 },
	{ "alloc",		KSTAT_DATA_UINT64 },
	{ "alloc_fail",		KSTAT_DATA_UINT64 },
	{ "free",		KSTAT_DATA_UINT64 },
	{ "depot_alloc",	KSTAT_DATA_UINT64 },
	{ "depot_free",		KSTAT_DATA_UINT64 },
	{ "depot_contention",	KSTAT_DATA_UINT64 },
	{ "slab_alloc",		KSTAT_DATA_UINT64 },
	{ "slab_free",		KSTAT_DATA_UINT64 },
	{ "buf_constructed",	KSTAT_DATA_UINT64 },
	{ "buf_avail",		KSTAT_DATA_UINT64 },
	{ "buf_inuse",		KSTAT_DATA_UINT64 },
	{ "buf_total",		KSTAT_DATA_UINT64 },
	{ "buf_max",		KSTAT_DATA_UINT64 },
	{ "slab_create",	KSTAT_DATA_UINT64 },
	{ "slab_destroy",	KSTAT_DATA_UINT64 },
	{ "vmem_source",	KSTAT_DATA_UINT64 },
	{ "hash_size",		KSTAT_DATA_UINT64 },
	{ "hash_lookup_depth",	KSTAT_DATA_UINT64 },
	{ "hash_rescale",	KSTAT_DATA_UINT64 },
	{ "full_magazines",	KSTAT_DATA_UINT64 },
	{ "empty_magazines",	KSTAT_DATA_UINT64 },
	{ "magazine_size",	KSTAT_DATA_UINT64 },
	{ "reap",		KSTAT_DATA_UINT64 },
	{ "defrag",		KSTAT_DATA_UINT64 },
	{ "scan",		KSTAT_DATA_UINT64 },
	{ "move_callbacks",	KSTAT_DATA_UINT64 },
	{ "move_yes",		KSTAT_DATA_UINT64 },
	{ "move_no",		KSTAT_DATA_UINT64 },
	{ "move_later",		KSTAT_DATA_UINT64 },
	{ "move_dont_need",	KSTAT_DATA_UINT64 },
	{ "move_dont_know",	KSTAT_DATA_UINT64 },
	{ "move_hunt_found",	KSTAT_DATA_UINT64 },
	{ "move_slabs_freed",	KSTAT_DATA_UINT64 },
	{ "move_reclaimable",	KSTAT_DATA_UINT64 },
};

static kmutex_t kmem_cache_kstat_lock;

/*
 * The default set of caches to back kmem_alloc().
 * These sizes should be reevaluated periodically.
 *
 * We want allocations that are multiples of the coherency granularity
 * (64 bytes) to be satisfied from a cache which is a multiple of 64
 * bytes, so that it will be 64-byte aligned.  For all multiples of 64,
 * the next kmem_cache_size greater than or equal to it must be a
 * multiple of 64.
 *
 * We split the table into two sections:  size <= 4k and size > 4k.  This
 * saves a lot of space and cache footprint in our cache tables.
 */
static const int kmem_alloc_sizes[] = {
	1 * 8,
	2 * 8,
	3 * 8,
	4 * 8,		5 * 8,		6 * 8,		7 * 8,
	4 * 16,		5 * 16,		6 * 16,		7 * 16,
	4 * 32,		5 * 32,		6 * 32,		7 * 32,
	4 * 64,		5 * 64,		6 * 64,		7 * 64,
	4 * 128,	5 * 128,	6 * 128,	7 * 128,
	P2ALIGN(8192 / 7, 64),
	P2ALIGN(8192 / 6, 64),
	P2ALIGN(8192 / 5, 64),
	P2ALIGN(8192 / 4, 64),
	P2ALIGN(8192 / 3, 64),
	P2ALIGN(8192 / 2, 64),
};

static const int kmem_big_alloc_sizes[] = {
	2 * 4096,	3 * 4096,
	2 * 8192,	3 * 8192,
	4 * 8192,	5 * 8192,	6 * 8192,	7 * 8192,
	8 * 8192,	9 * 8192,	10 * 8192,	11 * 8192,
	12 * 8192,	13 * 8192,	14 * 8192,	15 * 8192,
	16 * 8192
};

#define	KMEM_MAXBUF		4096
#define	KMEM_BIG_MAXBUF_32BIT	32768
#define	KMEM_BIG_MAXBUF		131072

#define	KMEM_BIG_MULTIPLE	4096	/* big_alloc_sizes must be a multiple */
#define	KMEM_BIG_SHIFT		12	/* lg(KMEM_BIG_MULTIPLE) */

static kmem_cache_t *kmem_alloc_table[KMEM_MAXBUF >> KMEM_ALIGN_SHIFT];
static kmem_cache_t *kmem_big_alloc_table[KMEM_BIG_MAXBUF >> KMEM_BIG_SHIFT];

#define	KMEM_ALLOC_TABLE_MAX	(KMEM_MAXBUF >> KMEM_ALIGN_SHIFT)
static size_t kmem_big_alloc_table_max = 0;	/* # of filled elements */

static kmem_magtype_t kmem_magtype[] = {
	{ 1,	8,	3200,	65536	},
	{ 3,	16,	256,	32768	},
	{ 7,	32,	64,	16384	},
	{ 15,	64,	0,	8192	},
	{ 31,	64,	0,	4096	},
	{ 47,	64,	0,	2048	},
	{ 63,	64,	0,	1024	},
	{ 95,	64,	0,	512	},
	{ 143,	64,	0,	0	},
};

static uint32_t kmem_reaping;
static uint32_t kmem_reaping_idspace;

/*
 * kmem tunables
 */
clock_t kmem_reap_interval;	/* cache reaping rate [15 * HZ ticks] */
int kmem_depot_contention = 3;	/* max failed tryenters per real interval */
pgcnt_t kmem_reapahead = 0;	/* start reaping N pages before pageout */
int kmem_panic = 1;		/* whether to panic on error */
int kmem_logging = 1;		/* kmem_log_enter() override */
uint32_t kmem_mtbf = 0;		/* mean time between failures [default: off] */
size_t kmem_transaction_log_size; /* transaction log size [2% of memory] */
size_t kmem_content_log_size;	/* content log size [2% of memory] */
size_t kmem_failure_log_size;	/* failure log [4 pages per CPU] */
size_t kmem_slab_log_size;	/* slab create log [4 pages per CPU] */
size_t kmem_zerosized_log_size;	/* zero-sized log [4 pages per CPU] */
size_t kmem_content_maxsave = 256; /* KMF_CONTENTS max bytes to log */
size_t kmem_lite_minsize = 0;	/* minimum buffer size for KMF_LITE */
size_t kmem_lite_maxalign = 1024; /* maximum buffer alignment for KMF_LITE */
int kmem_lite_pcs = 4;		/* number of PCs to store in KMF_LITE mode */
size_t kmem_maxverify;		/* maximum bytes to inspect in debug routines */
size_t kmem_minfirewall;	/* hardware-enforced redzone threshold */

#ifdef DEBUG
int kmem_warn_zerosized = 1;	/* whether to warn on zero-sized KM_SLEEP */
#else
int kmem_warn_zerosized = 0;	/* whether to warn on zero-sized KM_SLEEP */
#endif

int kmem_panic_zerosized = 0;	/* whether to panic on zero-sized KM_SLEEP */

#ifdef _LP64
size_t	kmem_max_cached = KMEM_BIG_MAXBUF;	/* maximum kmem_alloc cache */
#else
size_t	kmem_max_cached = KMEM_BIG_MAXBUF_32BIT; /* maximum kmem_alloc cache */
#endif

#ifdef DEBUG
int kmem_flags = KMF_AUDIT | KMF_DEADBEEF | KMF_REDZONE | KMF_CONTENTS;
#else
int kmem_flags = 0;
#endif
int kmem_ready;

static kmem_cache_t	*kmem_slab_cache;
static kmem_cache_t	*kmem_bufctl_cache;
static kmem_cache_t	*kmem_bufctl_audit_cache;

static kmutex_t		kmem_cache_lock;	/* inter-cache linkage only */
static list_t		kmem_caches;

static taskq_t		*kmem_taskq;
static kmutex_t		kmem_flags_lock;
static vmem_t		*kmem_metadata_arena;
static vmem_t		*kmem_msb_arena;	/* arena for metadata caches */
static vmem_t		*kmem_cache_arena;
static vmem_t		*kmem_hash_arena;
static vmem_t		*kmem_log_arena;
static vmem_t		*kmem_oversize_arena;
static vmem_t		*kmem_va_arena;
static vmem_t		*kmem_default_arena;
static vmem_t		*kmem_firewall_va_arena;
static vmem_t		*kmem_firewall_arena;

static int		kmem_zerosized;		/* # of zero-sized allocs */

/*
 * kmem slab consolidator thresholds (tunables)
 */
size_t kmem_frag_minslabs = 101;	/* minimum total slabs */
size_t kmem_frag_numer = 1;		/* free buffers (numerator) */
size_t kmem_frag_denom = KMEM_VOID_FRACTION; /* buffers (denominator) */
/*
 * Maximum number of slabs from which to move buffers during a single
 * maintenance interval while the system is not low on memory.
 */
size_t kmem_reclaim_max_slabs = 1;
/*
 * Number of slabs to scan backwards from the end of the partial slab list
 * when searching for buffers to relocate.
 */
size_t kmem_reclaim_scan_range = 12;

/* consolidator knobs */
boolean_t kmem_move_noreap;
boolean_t kmem_move_blocked;
boolean_t kmem_move_fulltilt;
boolean_t kmem_move_any_partial;

#ifdef	DEBUG
/*
 * kmem consolidator debug tunables:
 * Ensure code coverage by occasionally running the consolidator even when the
 * caches are not fragmented (they may never be). These intervals are mean time
 * in cache maintenance intervals (kmem_cache_update).
 */
uint32_t kmem_mtb_move = 60;	/* defrag 1 slab (~15min) */
uint32_t kmem_mtb_reap = 1800;	/* defrag all slabs (~7.5hrs) */
#endif	/* DEBUG */