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