aboutsummaryrefslogtreecommitdiff
path: root/Documentation/vm
diff options
context:
space:
mode:
authorChristoph Lameter <clameter@sgi.com>2007-08-07 15:11:48 -0700
committerChristoph Lameter <clameter@sgi.com>2007-08-09 21:57:16 -0700
commit1ceef40249f21eceabf8633934d94962e7d8e1d7 (patch)
tree2b9201a2f7b102d0db7f2790df6f6456fae89e21 /Documentation/vm
parentfcda3d89bf1366f6801447eab2d8a75ac5b9c4ce (diff)
SLUB: Fix dynamic dma kmalloc cache creation
The dynamic dma kmalloc creation can run into trouble if a GFP_ATOMIC allocation is the first one performed for a certain size of dma kmalloc slab. - Move the adding of the slab to sysfs into a workqueue (sysfs does GFP_KERNEL allocations) - Do not call kmem_cache_destroy() (uses slub_lock) - Only acquire the slub_lock once and--if we cannot wait--do a trylock. This introduces a slight risk of the first kmalloc(x, GFP_DMA|GFP_ATOMIC) for a range of sizes failing due to another process holding the slub_lock. However, we only need to acquire the spinlock once in order to establish each power of two DMA kmalloc cache. The possible conflict is with the slub_lock taken during slab management actions (create / remove slab cache). It is rather typical that a driver will first fill its buffers using GFP_KERNEL allocations which will wait until the slub_lock can be acquired. Drivers will also create its slab caches first outside of an atomic context before starting to use atomic kmalloc from an interrupt context. If there are any failures then they will occur early after boot or when loading of multiple drivers concurrently. Drivers can already accomodate failures of GFP_ATOMIC for other reasons. Retries will then create the slab. Signed-off-by: Christoph Lameter <clameter@sgi.com>
Diffstat (limited to 'Documentation/vm')
0 files changed, 0 insertions, 0 deletions