Prev: [PATCH block#for-2.6.36] block_dev: always serialize exclusive open attempts
Next: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Christoph Lameter on 4 Aug 2010 11:50 On Wed, 4 Aug 2010, Peter Crosthwaite wrote: > Because the buffer was too large for kmalloc, the kmalloc call would > fail. I traced the alloc_bootmem_low_pages() call further and > discovered that since the kmalloc call was failing, it was falling > back to alloc_bootmem_core(). So does this mean that the bootmem > allocator is trying to allocate memory while the slab allocator is up > and running? And is this supposed to work? The bootmem allocator should not work when slab is fully up. However, there is a grey period where the page allocator is not fully functional yet but the slab allocator is mostly working. > The reason i ask, is that when testing the system under high memory > usage conditions, I would get a "Bad page state" BUG() for my > allocated pages (see below). I have matched the pfns and confirmed > that they correspond to the pages allocated by the > alloc_bootmem_low_pages(). My theory is that the slab allocators list > of free pages does not get updated by the bootmem allocator, so the > slab allocator is seeing my DMA buffer as un-allocated. Does this > sound correct? bootmem allocations do not reserve page structs. So you do not have a page state at all. If you do something that requires a page state then you will have strange failures. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Lameter on 4 Aug 2010 14:10
Note also that allocating a 64M buffer will be difficult due to the maximum allocation size restrictions of the page allocator. You therefore have no choice but to allocate the memory at boot time. Or (if you have control over the arch) increase the maximum allocation unit (MAX_ORDER I believe). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |