Print this page
    
5513 KM_NORMALPRI should be documented in kmem_alloc(9f) and kmem_cache_create(9f) man pages
14465 Present KM_NOSLEEP_LAZY as documented interface
Change-Id: I002ec28ddf390650f1fcba1ca94f6abfdb241439
    
      
        | Split | 
	Close | 
      
      | Expand all | 
      | Collapse all | 
    
    
          --- old/usr/src/man/man9f/kmem_cache_create.9f
          +++ new/usr/src/man/man9f/kmem_cache_create.9f
   1    1  '\" te
   2    2  .\" Copyright 2015 Nexenta Systems, Inc.  All rights reserved.
        3 +.\" Copyright 2022 Joyent, Inc.
   3    4  .\" Copyright (c) 2002, Sun Microsystems, Inc. All Rights Reserved.
   4    5  .\" 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.
   5    6  .\" 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.
   6    7  .\" 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]
   7    8  .TH KMEM_CACHE_CREATE 9F "Feb 18, 2015"
   8    9  .SH NAME
   9   10  kmem_cache_create, kmem_cache_alloc, kmem_cache_free, kmem_cache_destroy,
  10   11  kmem_cache_set_move \- kernel memory cache allocator operations
  11   12  .SH SYNOPSIS
  12   13  .nf
  13   14  #include <sys/types.h>
  14   15  #include <sys/kmem.h>
  15   16  
  16   17  \fBkmem_cache_t *\fR\fBkmem_cache_create\fR(\fBchar *\fR\fIname\fR, \fBsize_t\fR \fIbufsize\fR,
  17   18       \fBsize_t\fR \fIalign\fR, \fBint\fR (*\fIconstructor\fR)(void *, void *, int),
  18   19       \fBvoid\fR (*\fIdestructor\fR)(void *, void *), \fBvoid\fR (*\fIreclaim\fR)(void *),
  19   20       \fBvoid\fR *\fIprivate\fR, \fBvoid\fR *\fIvmp\fR, \fBint\fR \fIcflags\fR);
  20   21  .fi
  21   22  
  22   23  .LP
  23   24  .nf
  24   25  \fBvoid\fR \fBkmem_cache_destroy\fR(\fBkmem_cache_t\fR *\fIcp\fR);
  25   26  .fi
  26   27  
  27   28  .LP
  28   29  .nf
  29   30  \fBvoid *\fR\fBkmem_cache_alloc\fR(\fBkmem_cache_t\fR *\fIcp\fR, \fBint\fR \fIkmflag\fR);
  30   31  .fi
  31   32  
  32   33  .LP
  33   34  .nf
  34   35  \fBvoid\fR \fBkmem_cache_free\fR(\fBkmem_cache_t\fR *\fIcp\fR, \fBvoid\fR *\fIobj\fR);
  35   36  .fi
  36   37  
  37   38  .LP
  38   39  .nf
  39   40  \fBvoid\fR \fBkmem_cache_set_move\fR(\fBkmem_cache_t\fR *\fIcp\fR, \fBkmem_cbrc_t\fR (*\fImove\fR)(\fBvoid\fR *,
  40   41       \fBvoid\fR *, \fBsize_t\fR *, \fBvoid\fR *));
  41   42  .fi
  42   43  
  43   44  .LP
  44   45  .nf
  45   46   [Synopsis for callback functions:]
  46   47  .fi
  47   48  
  48   49  .LP
  49   50  .nf
  50   51  \fBint\fR (*\fIconstructor\fR)(\fBvoid\fR *\fIbuf\fR, \fBvoid\fR *\fIuser_arg\fR, \fBint\fR \fIkmflags\fR);
  51   52  .fi
  52   53  
  53   54  .LP
  54   55  .nf
  55   56  \fBvoid\fR (*\fIdestructor\fR)(\fBvoid\fR *\fIbuf\fR, \fBvoid\fR *\fIuser_arg\fR);
  56   57  .fi
  57   58  
  58   59  .LP
  59   60  .nf
  60   61  \fBkmem_cbrc_t\fR (*\fImove\fR)(\fBvoid\fR *\fIold\fR, \fBvoid\fR *\fInew\fR, \fBsize_t\fR \fIbufsize\fR,
  61   62       \fBvoid\fR *\fIuser_arg\fR);
  62   63  .fi
  63   64  
  64   65  .SH INTERFACE LEVEL
  65   66  illumos DDI specific (illumos DDI)
  66   67  .SH PARAMETERS
  67   68  The parameters for the \fBkmem_cache_*\fR functions are as follows:
  68   69  .sp
  69   70  .ne 2
  70   71  .na
  71   72  \fB\fIname\fR\fR
  72   73  .ad
  73   74  .RS 15n
  74   75  Descriptive name of a \fBkstat\fR(9S) structure of class \fBkmem_cache\fR.
  75   76  Names longer than 31 characters are truncated.
  76   77  .RE
  77   78  
  78   79  .sp
  79   80  .ne 2
  80   81  .na
  81   82  \fB\fIbufsize\fR\fR
  82   83  .ad
  83   84  .RS 15n
  84   85  Size of the objects it manages.
  85   86  .RE
  86   87  
  87   88  .sp
  88   89  .ne 2
  89   90  .na
  90   91  \fB\fIalign\fR\fR
  91   92  .ad
  92   93  .RS 15n
  93   94  Required object alignment.
  94   95  .RE
  95   96  
  96   97  .sp
  97   98  .ne 2
  98   99  .na
  99  100  \fB\fIconstructor\fR\fR
 100  101  .ad
 101  102  .RS 15n
 102  103  Pointer to an object constructor function. Parameters are defined below.
 103  104  .RE
 104  105  
 105  106  .sp
 106  107  .ne 2
 107  108  .na
 108  109  \fB\fIdestructor\fR\fR
 109  110  .ad
 110  111  .RS 15n
 111  112  Pointer to an object destructor function. Parameters are defined below.
 112  113  .RE
 113  114  
 114  115  .sp
 115  116  .ne 2
 116  117  .na
 117  118  \fB\fIreclaim\fR\fR
 118  119  .ad
 119  120  .RS 15n
 120  121  Drivers should pass \fBNULL\fR.
 121  122  .RE
 122  123  
 123  124  .sp
 124  125  .ne 2
 125  126  .na
 126  127  \fB\fIprivate\fR\fR
 127  128  .ad
 128  129  .RS 15n
 129  130  Pass-through argument for constructor/destructor.
 130  131  .RE
 131  132  
 132  133  .sp
 133  134  .ne 2
 134  135  .na
 135  136  \fB\fIvmp\fR\fR
 136  137  .ad
 137  138  .RS 15n
 138  139  Drivers should pass \fBNULL\fR.
 139  140  .RE
 140  141  
 141  142  .sp
 142  143  .ne 2
 143  144  .na
 144  145  \fB\fIcflags\fR\fR
 145  146  .ad
 146  147  .RS 15n
 147  148  Drivers must pass 0.
 148  149  .RE
 149  150  
 150  151  .sp
 151  152  .ne 2
 152  153  .na
 153  154  \fB\fIkmflag\fR\fR
 154  155  .ad
 155  156  .RS 15n
 156  157  Possible flags are:
 157  158  .sp
 158  159  .ne 2
 159  160  .na
 160  161  \fB\fBKM_SLEEP\fR\fR
 161  162  .ad
  
    | 
      ↓ open down ↓ | 
    149 lines elided | 
    
      ↑ open up ↑ | 
  
 162  163  .RS 15n
 163  164  Allow sleeping (blocking) until memory is available.
 164  165  .RE
 165  166  
 166  167  .sp
 167  168  .ne 2
 168  169  .na
 169  170  \fB\fBKM_NOSLEEP\fR\fR
 170  171  .ad
 171  172  .RS 15n
 172      -Return NULL immediately if memory is not available.
      173 +Return NULL immediately if memory is not available, but after an aggressive
      174 +reclaiming attempt.  Any mention of \fBKM_NOSLEEP\fR without mentioning
      175 +\fBKM_NOSLEEP_LAZY\fR (see below) applies to both values.
 173  176  .RE
 174  177  
 175  178  .sp
 176  179  .ne 2
 177  180  .na
      181 +\fB\fBKM_NOSLEEP_LAZY\fR\fR
      182 +.ad
      183 +.RS 15n
      184 +Return NULL immediately if memory is not available, without the aggressive
      185 +reclaiming attempt.  This is actually two flags combined:
      186 +(\fBKM_NOSLEEP\fR | \fBKM_NORMALPRI\fR), the latter flag indicating not to
      187 +attempt reclamation before giving up and returning NULL.
      188 +.RE
      189 +
      190 +.sp
      191 +.ne 2
      192 +.na
 178  193  \fB\fBKM_PUSHPAGE\fR\fR
 179  194  .ad
 180  195  .RS 15n
 181  196  Allow the allocation to use reserved memory.
 182  197  .RE
 183  198  
 184  199  .RE
 185  200  
 186  201  .sp
 187  202  .ne 2
 188  203  .na
 189  204  \fB\fIobj\fR\fR
 190  205  .ad
 191  206  .RS 15n
 192  207  Pointer to the object allocated by \fBkmem_cache_alloc()\fR.
 193  208  .RE
 194  209  
 195  210  .sp
 196  211  .ne 2
 197  212  .na
 198  213  \fB\fImove\fR\fR
 199  214  .ad
 200  215  .RS 15n
 201  216  Pointer to an object relocation function. Parameters are defined below.
 202  217  .RE
 203  218  
 204  219  .sp
 205  220  .LP
 206  221  The parameters for the callback constructor function are as follows:
 207  222  .sp
 208  223  .ne 2
 209  224  .na
 210  225  \fB\fBvoid *\fIbuf\fR\fR\fR
 211  226  .ad
 212  227  .RS 18n
 213  228  Pointer to the object to be constructed.
 214  229  .RE
 215  230  
 216  231  .sp
 217  232  .ne 2
 218  233  .na
 219  234  \fB\fBvoid *\fIuser_arg\fR\fR\fR
 220  235  .ad
 221  236  .RS 18n
 222  237  The \fIprivate\fR parameter from the call to \fBkmem_cache_create()\fR; it is
 223  238  typically a pointer to the soft-state structure.
 224  239  .RE
 225  240  
 226  241  .sp
 227  242  .ne 2
 228  243  .na
 229  244  \fB\fBint \fIkmflags\fR\fR\fR
 230  245  .ad
 231  246  .RS 18n
 232  247  Propagated \fIkmflag\fR values.
 233  248  .RE
 234  249  
 235  250  .sp
 236  251  .LP
 237  252  The parameters for the callback destructor function are as follows:
 238  253  .sp
 239  254  .ne 2
 240  255  .na
 241  256  \fB\fBvoid *\fIbuf\fR\fR\fR
 242  257  .ad
 243  258  .RS 18n
 244  259  Pointer to the object to be deconstructed.
 245  260  .RE
 246  261  
 247  262  .sp
 248  263  .ne 2
 249  264  .na
 250  265  \fB\fBvoid *\fIuser_arg\fR\fR\fR
 251  266  .ad
 252  267  .RS 18n
 253  268  The \fIprivate\fR parameter from the call to \fBkmem_cache_create()\fR; it is
 254  269  typically a pointer to the soft-state structure.
 255  270  .RE
 256  271  
 257  272  .sp
 258  273  .LP
 259  274  The parameters for the callback \fBmove()\fR function are as follows:
 260  275  .sp
 261  276  .ne 2
 262  277  .na
 263  278  \fB\fBvoid *\fIold\fR\fR\fR
 264  279  .ad
 265  280  .RS 18n
 266  281  Pointer to the object to be moved.
 267  282  .RE
 268  283  
 269  284  .sp
 270  285  .ne 2
 271  286  .na
 272  287  \fB\fBvoid *\fInew\fR\fR\fR
 273  288  .ad
 274  289  .RS 18n
 275  290  Pointer to the object that serves as the copy destination for the contents of
 276  291  the old parameter.
 277  292  .RE
 278  293  
 279  294  .sp
 280  295  .ne 2
 281  296  .na
 282  297  \fB\fBsize_t \fIbufsize\fR\fR\fR
 283  298  .ad
 284  299  .RS 18n
 285  300  Size of the object to be moved.
 286  301  .RE
 287  302  
 288  303  .sp
 289  304  .ne 2
 290  305  .na
 291  306  \fB\fBvoid *\fIuser_arg\fR\fR\fR
 292  307  .ad
 293  308  .RS 18n
 294  309  The private parameter from the call to \fBkmem_cache_create()\fR; it is
 295  310  typically a pointer to the \fBsoft-state\fR structure.
 296  311  .RE
 297  312  
 298  313  .SH DESCRIPTION
 299  314  In many cases, the cost of initializing and destroying an object exceeds the
 300  315  cost of allocating and freeing memory for it. The functions described here
 301  316  address this condition.
 302  317  .sp
 303  318  .LP
 304  319  Object caching is a technique for dealing with objects that are:
 305  320  .RS +4
 306  321  .TP
 307  322  .ie t \(bu
 308  323  .el o
 309  324  frequently allocated and freed, and
 310  325  .RE
 311  326  .RS +4
 312  327  .TP
 313  328  .ie t \(bu
 314  329  .el o
 315  330  have setup and initialization costs.
 316  331  .RE
 317  332  .sp
 318  333  .LP
 319  334  The idea is to allow the allocator and its clients to cooperate to preserve the
 320  335  invariant portion of an object's initial state, or constructed state, between
 321  336  uses, so it does not have to be destroyed and re-created every time the object
 322  337  is used. For example, an object containing a mutex only needs to have
 323  338  \fBmutex_init()\fR applied once, the first time the object is allocated. The
 324  339  object can then be freed and reallocated many times without incurring the
 325  340  expense of \fBmutex_destroy()\fR and \fBmutex_init()\fR each time. An object's
 326  341  embedded locks, condition variables, reference counts, lists of other objects,
 327  342  and read-only data all generally qualify as constructed state. The essential
 328  343  requirement is that the client must free the object (using
 329  344  \fBkmem_cache_free()\fR) in its constructed state. The allocator cannot enforce
 330  345  this, so programming errors will lead to hard-to-find bugs.
 331  346  .sp
 332  347  .LP
 333  348  A driver should call \fBkmem_cache_create()\fR at the time of \fB_init\fR(9E)
 334  349  or \fBattach\fR(9E), and call the corresponding \fBkmem_cache_destroy()\fR at
 335  350  the time of \fB_fini\fR(9E) or \fBdetach\fR(9E).
 336  351  .sp
 337  352  .LP
 338  353  \fBkmem_cache_create()\fR creates a cache of objects, each of size
 339  354  \fIbufsize\fR bytes, aligned on an \fIalign\fR boundary. Drivers not requiring
 340  355  a specific alignment can pass 0. \fIname\fR identifies the cache for statistics
 341  356  and debugging. \fIconstructor\fR and \fIdestructor\fR convert plain memory into
 342  357  objects and back again; \fIconstructor\fR can fail if it needs to allocate
  
    | 
      ↓ open down ↓ | 
    155 lines elided | 
    
      ↑ open up ↑ | 
  
 343  358  memory but cannot. \fIprivate\fR is a parameter passed to the constructor and
 344  359  destructor callbacks to support parameterized caches (for example, a pointer to
 345  360  an instance of the driver's soft-state structure). To facilitate debugging,
 346  361  \fBkmem_cache_create()\fR creates a \fBkstat\fR(9S) structure of class
 347  362  \fBkmem_cache\fR and name \fIname\fR. It returns an opaque pointer to the
 348  363  object cache.
 349  364  .sp
 350  365  .LP
 351  366  \fBkmem_cache_alloc()\fR gets an object from the cache. The object will be in
 352  367  its constructed state. \fIkmflag\fR has either \fBKM_SLEEP\fR or
 353      -\fBKM_NOSLEEP\fR set, indicating whether it is acceptable to wait for memory if
 354      -none is currently available.
      368 +\fBKM_NOSLEEP\fR set, indicating whether it is acceptable to wait for memory
      369 +if none is currently available.
 355  370  .sp
 356  371  .LP
 357  372  A small pool of reserved memory is available to allow the system to progress
 358  373  toward the goal of freeing additional memory while in a low memory situation.
 359  374  The \fBKM_PUSHPAGE\fR flag enables use of this reserved memory pool on an
 360  375  allocation. This flag can be used by drivers that implement \fBstrategy\fR(9E)
 361  376  on memory allocations associated with a single I/O operation. The driver
 362  377  guarantees that the I/O operation will complete (or timeout) and, on
 363  378  completion, that the memory will be returned. The \fBKM_PUSHPAGE\fR flag should
 364  379  be used only in \fBkmem_cache_alloc()\fR calls. All allocations from a given
 365  380  cache should be consistent in their use of the flag. A driver that adheres to
 366  381  these restrictions can guarantee progress in a low memory situation without
 367  382  resorting to complex private allocation and queuing schemes. If
 368  383  \fBKM_PUSHPAGE\fR is specified, \fBKM_SLEEP\fR can also be used without causing
 369  384  deadlock.
 370  385  .sp
 371  386  .LP
 372  387  \fBkmem_cache_free()\fR returns an object to the cache. The object must be in
 373  388  its constructed state.
 374  389  .sp
 375  390  .LP
 376  391  \fBkmem_cache_destroy()\fR destroys the cache and releases all associated
 377  392  resources. All allocated objects must have been previously freed.
 378  393  .sp
 379  394  .LP
 380  395  \fBkmem_cache_set_move()\fR registers a function that the allocator may call to
 381  396  move objects from sparsely allocated pages of memory so that the system can
 382  397  reclaim pages that are tied up by the client. Since caching objects of the same
 383  398  size and type already makes severe memory fragmentation unlikely, there is
 384  399  generally no need to register such a function. The idea is to make it possible
 385  400  to limit worst-case fragmentation in caches that exhibit a tendency to become
 386  401  highly fragmented. Only clients that allocate a mix of long- and short-lived
 387  402  objects from the same cache are prone to exhibit this tendency, making them
 388  403  candidates for a \fBmove()\fR callback.
 389  404  .sp
 390  405  .LP
 391  406  The \fBmove()\fR callback supplies the client with two addresses: the allocated
 392  407  object that the allocator wants to move and a buffer selected by the allocator
 393  408  for the client to use as the copy destination. The new parameter is an
 394  409  allocated, constructed object ready to receive the contents of the old
 395  410  parameter. The \fIbufsize\fR parameter supplies the size of the object, in case
 396  411  a single move function handles multiple caches whose objects differ only in
 397  412  size. Finally, the private parameter passed to the constructor and destructor
 398  413  is also passed to the \fBmove()\fR callback.
 399  414  .sp
 400  415  .LP
 401  416  Only the client knows about its own data and when it is a good time to move it.
 402  417  The client cooperates with the allocator to return unused memory to the system,
 403  418  and the allocator accepts this help at the client's convenience. When asked to
 404  419  move an object, the client can respond with any of the following:
 405  420  .sp
 406  421  .in +2
 407  422  .nf
 408  423  typedef enum kmem_cbrc {
 409  424               KMEM_CBRC_YES,
 410  425               KMEM_CBRC_NO,
 411  426               KMEM_CBRC_LATER,
 412  427               KMEM_CBRC_DONT_NEED,
 413  428               KMEM_CBRC_DONT_KNOW
 414  429  } kmem_cbrc_t;
 415  430  .fi
 416  431  .in -2
 417  432  .sp
 418  433  
 419  434  .sp
 420  435  .LP
 421  436  The client must not explicitly free either of the objects passed to the
 422  437  \fBmove()\fR callback, since the allocator wants to free them directly to the
 423  438  slab layer (bypassing the per-CPU magazine layer). The response tells the
 424  439  allocator which of the two object parameters to free:
 425  440  .sp
 426  441  .ne 2
 427  442  .na
 428  443  \fB\fBKMEM_CBRC_YES\fR\fR
 429  444  .ad
 430  445  .RS 23n
 431  446  The client moved the object; the allocator frees the old parameter.
 432  447  .RE
 433  448  
 434  449  .sp
 435  450  .ne 2
 436  451  .na
 437  452  \fB\fBKMEM_CBRC_NO\fR\fR
 438  453  .ad
 439  454  .RS 23n
 440  455  The client refused to move the object; the allocator frees the new parameter
 441  456  (the unused copy destination).
 442  457  .RE
 443  458  
 444  459  .sp
 445  460  .ne 2
 446  461  .na
 447  462  \fB\fBKMEM_CBRC_LATER\fR\fR
 448  463  .ad
 449  464  .RS 23n
 450  465  The client is using the object and cannot move it now; the allocator frees the
 451  466  new parameter (the unused copy destination). The client should use
 452  467  \fBKMEM_CBRC_LATER\fR instead of \fBKMEM_CBRC_NO\fR if the object is likely to
 453  468  become movable soon.
 454  469  .RE
 455  470  
 456  471  .sp
 457  472  .ne 2
 458  473  .na
 459  474  \fB\fBKMEM_CBRC_DONT_NEED\fR\fR
 460  475  .ad
 461  476  .RS 23n
 462  477  The client no longer needs the object; the allocator frees both the old and new
 463  478  parameters. This response is the client's opportunity to be a model citizen and
 464  479  give back as much as it can.
 465  480  .RE
 466  481  
 467  482  .sp
 468  483  .ne 2
 469  484  .na
 470  485  \fB\fBKMEM_CBRC_DONT_KNOW\fR\fR
 471  486  .ad
 472  487  .RS 23n
 473  488  The client does not know about the object because:
 474  489  .sp
 475  490  .ne 2
 476  491  .na
 477  492  \fBa)\fR
 478  493  .ad
 479  494  .RS 6n
 480  495  the client has just allocated the object and has not yet put it wherever it
 481  496  expects to find known objects
 482  497  .RE
 483  498  
 484  499  .sp
 485  500  .ne 2
 486  501  .na
 487  502  \fBb)\fR
 488  503  .ad
 489  504  .RS 6n
 490  505  the client has removed the object from wherever it expects to find known
 491  506  objects and is about to free the object
 492  507  .RE
 493  508  
 494  509  .sp
 495  510  .ne 2
 496  511  .na
 497  512  \fBc)\fR
 498  513  .ad
 499  514  .RS 6n
 500  515  the client has freed the object
 501  516  .RE
 502  517  
 503  518  In all of these cases above, the allocator frees the new parameter (the unused
 504  519  copy destination) and searches for the old parameter in the magazine layer. If
 505  520  the object is found, it is removed from the magazine layer and freed to the
 506  521  slab layer so that it will no longer tie up an entire page of memory.
 507  522  .RE
 508  523  
 509  524  .sp
 510  525  .LP
 511  526  Any object passed to the \fBmove()\fR callback is guaranteed to have been
 512  527  touched only by the allocator or by the client. Because memory patterns applied
 513  528  by the allocator always set at least one of the two lowest order bits, the
 514  529  bottom two bits of any pointer member (other than \fBchar *\fR or \fBshort
 515  530  *\fR, which may not be 8-byte aligned on all platforms) are available to the
 516  531  client for marking cached objects that the client is about to free. This way,
 517  532  the client can recognize known objects in the \fBmove()\fR callback by the
 518  533  unmarked (valid) pointer value.
 519  534  .sp
 520  535  .LP
 521  536  If the client refuses to move an object with either \fBKMEM_CBRC_NO\fR or
 522  537  \fBKMEM_CBRC_LATER\fR, and that object later becomes movable, the client can
 523  538  notify the allocator by calling \fBkmem_cache_move_notify()\fR. Alternatively,
 524  539  the client can simply wait for the allocator to call back again with the same
 525  540  object address. Responding \fBKMEM_CRBC_NO\fR even once or responding
 526  541  \fBKMEM_CRBC_LATER\fR too many times for the same object makes the allocator
 527  542  less likely to call back again for that object.
 528  543  .LP
 529  544  .nf
 530  545  [Synopsis for notification function:]
 531  546  .fi
 532  547  
 533  548  .LP
 534  549  .nf
 535  550  \fBvoid\fR \fBkmem_cache_move_notify\fR(\fBkmem_cache_t\fR *\fIcp\fR, \fBvoid\fR *\fIobj\fR);
 536  551  .fi
 537  552  
 538  553  .sp
 539  554  .LP
 540  555  The parameters for the \fBnotification\fR function are as follows:
 541  556  .sp
 542  557  .ne 2
 543  558  .na
 544  559  \fB\fIcp\fR\fR
 545  560  .ad
 546  561  .RS 7n
 547  562  Pointer to the object cache.
 548  563  .RE
 549  564  
 550  565  .sp
 551  566  .ne 2
 552  567  .na
 553  568  \fB\fIobj\fR\fR
 554  569  .ad
 555  570  .RS 7n
 556  571  Pointer to the object that has become movable since an earlier refusal to move
 557  572  it.
 558  573  .RE
 559  574  
 560  575  .SH CONTEXT
 561  576  Constructors can be invoked during any call to \fBkmem_cache_alloc()\fR, and
 562  577  will run in that context. Similarly, destructors can be invoked during any call
 563  578  to \fBkmem_cache_free()\fR, and can also be invoked during
 564  579  \fBkmem_cache_destroy()\fR. Therefore, the functions that a constructor or
 565  580  destructor invokes must be appropriate in that context. Furthermore, the
  
    | 
      ↓ open down ↓ | 
    201 lines elided | 
    
      ↑ open up ↑ | 
  
 566  581  allocator may also call the constructor and destructor on objects still under
 567  582  its control without client involvement.
 568  583  .sp
 569  584  .LP
 570  585  \fBkmem_cache_create()\fR and \fBkmem_cache_destroy()\fR must not be called
 571  586  from interrupt context. \fBkmem_cache_create()\fR can also block for available
 572  587  memory.
 573  588  .sp
 574  589  .LP
 575  590  \fBkmem_cache_alloc()\fR can be called from interrupt context only if the
 576      -\fBKM_NOSLEEP\fR flag is set. It can be called from user or kernel context with
 577      -any valid flag.
      591 +\fBKM_NOSLEEP\fR flag is set. It can be called from user or kernel context
      592 +with any valid flag.
 578  593  .sp
 579  594  .LP
 580  595  \fBkmem_cache_free()\fR can be called from user, kernel, or interrupt context.
 581  596  .sp
 582  597  .LP
 583  598  \fBkmem_cache_set_move()\fR is called from the same context as
 584  599  \fBkmem_cache_create()\fR, immediately after \fBkmem_cache_create()\fR and
 585  600  before allocating any objects from the cache.
 586  601  .sp
 587  602  .LP
 588  603  The registered \fBmove()\fR callback is always invoked in the same global
 589  604  callback thread dedicated for move requests, guaranteeing that no matter how
 590  605  many clients register a \fBmove()\fR function, the allocator never tries to
 591  606  move more than one object at a time. Neither the allocator nor the client can
 592  607  be assumed to know the object's whereabouts at the time of the callback.
 593  608  .SH EXAMPLES
 594  609  \fBExample 1 \fRObject Caching
 595  610  .sp
 596  611  .LP
 597  612  Consider the following data structure:
 598  613  
 599  614  .sp
 600  615  .in +2
 601  616  .nf
 602  617  struct foo {
 603  618      kmutex_t foo_lock;
 604  619      kcondvar_t foo_cv;
 605  620      struct bar *foo_barlist;
 606  621      int foo_refcnt;
 607  622      };
 608  623  .fi
 609  624  .in -2
 610  625  
 611  626  .sp
 612  627  .LP
 613  628  Assume that a \fBfoo\fR structure cannot be freed until there are no
 614  629  outstanding references to it (\fBfoo_refcnt == 0\fR) and all of its pending
 615  630  \fBbar\fR events (whatever they are) have completed (\fBfoo_barlist ==
 616  631  NULL\fR). The life cycle of a dynamically allocated \fBfoo\fR would be
 617  632  something like this:
 618  633  
 619  634  .sp
 620  635  .in +2
 621  636  .nf
 622  637  foo = kmem_alloc(sizeof (struct foo), KM_SLEEP);
 623  638  mutex_init(&foo->foo_lock, ...);
 624  639  cv_init(&foo->foo_cv, ...);
 625  640  foo->foo_refcnt = 0;
 626  641  foo->foo_barlist = NULL;
 627  642      use foo;
 628  643  ASSERT(foo->foo_barlist == NULL);
 629  644  ASSERT(foo->foo_refcnt == 0);
 630  645  cv_destroy(&foo->foo_cv);
 631  646  mutex_destroy(&foo->foo_lock);
 632  647  kmem_free(foo);
 633  648  .fi
 634  649  .in -2
 635  650  
 636  651  .sp
 637  652  .LP
 638  653  Notice that between each use of a \fBfoo\fR object we perform a sequence of
 639  654  operations that constitutes nothing but expensive overhead. All of this
 640  655  overhead (that is, everything other than \fBuse foo\fR above) can be eliminated
 641  656  by object caching.
 642  657  
 643  658  .sp
 644  659  .in +2
 645  660  .nf
 646  661  int
 647  662  foo_constructor(void *buf, void *arg, int tags)
 648  663  {
 649  664      struct foo *foo = buf;
 650  665      mutex_init(&foo->foo_lock, ...);
 651  666      cv_init(&foo->foo_cv, ...);
 652  667      foo->foo_refcnt = 0;
 653  668      foo->foo_barlist = NULL;
 654  669      return (0);
 655  670  }
 656  671  
 657  672  void
 658  673  foo_destructor(void *buf, void *arg)
 659  674  {
 660  675      struct foo *foo = buf;
 661  676      ASSERT(foo->foo_barlist == NULL);
 662  677      ASSERT(foo->foo_refcnt == 0);
 663  678      cv_destroy(&foo->foo_cv);
 664  679      mutex_destroy(&foo->foo_lock);
 665  680  }
 666  681  
 667  682  user_arg = ddi_get_soft_state(foo_softc, instance);
 668  683  (void) snprintf(buf, KSTAT_STRLEN, "foo%d_cache",
 669  684          ddi_get_instance(dip));
 670  685  foo_cache = kmem_cache_create(buf,
 671  686          sizeof (struct foo), 0,
 672  687          foo_constructor, foo_destructor,
 673  688          NULL, user_arg, 0);
 674  689  .fi
 675  690  .in -2
 676  691  
 677  692  .sp
 678  693  .LP
 679  694  To allocate, use, and free a \fBfoo\fR object:
 680  695  
 681  696  .sp
 682  697  .in +2
 683  698  .nf
 684  699  foo = kmem_cache_alloc(foo_cache, KM_SLEEP);
 685  700      use foo;
 686  701  kmem_cache_free(foo_cache, foo);
 687  702  .fi
 688  703  .in -2
 689  704  
 690  705  .sp
 691  706  .LP
 692  707  This makes \fBfoo\fR allocation fast, because the allocator will usually do
 693  708  nothing more than fetch an already-constructed \fBfoo\fR from the cache.
 694  709  \fBfoo_constructor\fR and \fBfoo_destructor\fR will be invoked only to populate
 695  710  and drain the cache, respectively.
 696  711  
 697  712  .LP
 698  713  \fBExample 2 \fRRegistering a Move Callback
 699  714  .sp
 700  715  .LP
 701  716  To register a \fBmove()\fR callback:
  
    | 
      ↓ open down ↓ | 
    114 lines elided | 
    
      ↑ open up ↑ | 
  
 702  717  
 703  718  .sp
 704  719  .in +2
 705  720  .nf
 706  721  object_cache = kmem_cache_create(...);
 707  722  kmem_cache_set_move(object_cache, object_move);
 708  723  .fi
 709  724  .in -2
 710  725  
 711  726  .SH RETURN VALUES
 712      -If successful, the constructor function must return \fB0\fR. If KM_NOSLEEP is
 713      -set and memory cannot be allocated without sleeping, the constructor must
 714      -return -\fB1\fR.
      727 +If successful, the constructor function must return \fB0\fR. If
      728 +\fBKM_NOSLEEP\fR or \fBKM_NOSLEEP_LAZY\fR is set and memory cannot be
      729 +allocated without sleeping, the constructor must return -\fB1\fR.  If the
      730 +constructor takes extraordinary steps during a \fBKM_NOSLEEP\fR construction,
      731 +it may not take those for a \fBKM_NOSLEEP_LAZY\fR construction.
 715  732  .sp
 716  733  .LP
 717  734  \fBkmem_cache_create()\fR returns a pointer to the allocated cache.
 718  735  .sp
 719  736  .LP
 720  737  If successful, \fBkmem_cache_alloc()\fR returns a pointer to the allocated
 721  738  object. If \fBKM_NOSLEEP\fR is set and memory cannot be allocated without
 722  739  sleeping, \fBkmem_cache_alloc()\fR returns \fBNULL\fR.
 723  740  .SH ATTRIBUTES
 724  741  See \fBattributes\fR(5) for descriptions of the following attributes:
 725  742  .sp
 726  743  
 727  744  .sp
 728  745  .TS
 729  746  box;
 730  747  c | c
 731  748  l | l .
 732  749  ATTRIBUTE TYPE  ATTRIBUTE VALUE
 733  750  _
 734  751  Interface Stability     Committed
 735  752  .TE
 736  753  
 737  754  .SH SEE ALSO
 738  755  \fBcondvar\fR(9F), \fBkmem_alloc\fR(9F), \fBmutex\fR(9F), \fBkstat\fR(9S)
 739  756  .sp
 740  757  .LP
 741  758  \fIWriting Device Drivers\fR
 742  759  .sp
 743  760  .LP
 744  761  \fIThe Slab Allocator: An Object-Caching Kernel Memory Allocator\fR, Bonwick,
 745  762  J.; USENIX Summer 1994 Technical Conference (1994).
 746  763  .sp
 747  764  .LP
 748  765  \fIMagazines and vmem: Extending the Slab Allocator to Many CPUs and Arbitrary
 749  766  Resources\fR, Bonwick, J. and Adams, J.; USENIX 2001 Technical Conference
 750  767  (2001).
 751  768  .SH NOTES
 752  769  The constructor must be immediately reversible by the destructor, since the
 753  770  allocator may call the constructor and destructor on objects still under its
 754  771  control at any time without client involvement.
 755  772  .sp
 756  773  .LP
 757  774  The constructor must respect the \fIkmflags\fR argument by forwarding it to
 758  775  allocations made inside the \fIconstructor\fR, and must not ASSERT anything
 759  776  about the given flags.
 760  777  .sp
 761  778  .LP
 762  779  The user argument forwarded to the constructor must be fully operational before
 763  780  it is passed to \fBkmem_cache_create()\fR.
  
    | 
      ↓ open down ↓ | 
    39 lines elided | 
    
      ↑ open up ↑ | 
  
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX