| uma_int.h (93818) | uma_int.h (94157) |
|---|---|
| 1/* 2 * Copyright (c) 2002, Jeffrey Roberson <jroberson@chesapeake.net> 3 * All rights reserved. 4 * 5 * Redistribution and use in source and binary forms, with or without 6 * modification, are permitted provided that the following conditions 7 * are met: 8 * 1. Redistributions of source code must retain the above copyright --- 9 unchanged lines hidden (view full) --- 18 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 19 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 20 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 21 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 22 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 23 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 24 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 25 * | 1/* 2 * Copyright (c) 2002, Jeffrey Roberson <jroberson@chesapeake.net> 3 * All rights reserved. 4 * 5 * Redistribution and use in source and binary forms, with or without 6 * modification, are permitted provided that the following conditions 7 * are met: 8 * 1. Redistributions of source code must retain the above copyright --- 9 unchanged lines hidden (view full) --- 18 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 19 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 20 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 21 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 22 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 23 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 24 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 25 * |
| 26 * $FreeBSD: head/sys/vm/uma_int.h 93818 2002-04-04 21:03:38Z jhb $ | 26 * $FreeBSD: head/sys/vm/uma_int.h 94157 2002-04-07 22:56:48Z jeff $ |
| 27 * 28 */ 29 30/* 31 * 32 * Jeff Roberson <jroberson@chesapeake.net> 33 * 34 * This file includes definitions, structures, prototypes, and inlines that --- 12 unchanged lines hidden (view full) --- 47 * for pages that don't have embedded uma_slab_t's. 48 * 49 * The uma_slab_t may be embedded in a UMA_SLAB_SIZE chunk of memory or it may 50 * be allocated off the page from a special slab zone. The free list within a 51 * slab is managed with a linked list of indexes, which are 8 bit values. If 52 * UMA_SLAB_SIZE is defined to be too large I will have to switch to 16bit 53 * values. Currently on alpha you can get 250 or so 32 byte items and on x86 54 * you can get 250 or so 16byte items. For item sizes that would yield more | 27 * 28 */ 29 30/* 31 * 32 * Jeff Roberson <jroberson@chesapeake.net> 33 * 34 * This file includes definitions, structures, prototypes, and inlines that --- 12 unchanged lines hidden (view full) --- 47 * for pages that don't have embedded uma_slab_t's. 48 * 49 * The uma_slab_t may be embedded in a UMA_SLAB_SIZE chunk of memory or it may 50 * be allocated off the page from a special slab zone. The free list within a 51 * slab is managed with a linked list of indexes, which are 8 bit values. If 52 * UMA_SLAB_SIZE is defined to be too large I will have to switch to 16bit 53 * values. Currently on alpha you can get 250 or so 32 byte items and on x86 54 * you can get 250 or so 16byte items. For item sizes that would yield more |
| 55 * than 10% memory waste we potentially allocate a seperate uma_slab_t if this | 55 * than 10% memory waste we potentially allocate a separate uma_slab_t if this |
| 56 * will improve the number of items per slab that will fit. 57 * 58 * Other potential space optimizations are storing the 8bit of linkage in space 59 * wasted between items due to alignment problems. This may yield a much better 60 * memory footprint for certain sizes of objects. Another alternative is to 61 * increase the UMA_SLAB_SIZE, or allow for dynamic slab sizes. I prefer 62 * dynamic slab sizes because we could stick with 8 bit indexes and only use 63 * large slab sizes for zones with a lot of waste per slab. This may create --- 267 unchanged lines hidden --- | 56 * will improve the number of items per slab that will fit. 57 * 58 * Other potential space optimizations are storing the 8bit of linkage in space 59 * wasted between items due to alignment problems. This may yield a much better 60 * memory footprint for certain sizes of objects. Another alternative is to 61 * increase the UMA_SLAB_SIZE, or allow for dynamic slab sizes. I prefer 62 * dynamic slab sizes because we could stick with 8 bit indexes and only use 63 * large slab sizes for zones with a lot of waste per slab. This may create --- 267 unchanged lines hidden --- |