Re: kernel BUG at mm/slub.c:3689!

["Håvard Skinnemoen" <hskinnemoen@gmail.com>]

On 6/11/07, Christoph Lameter <clameter@sgi.com> wrote:
> Ok. Drop the patch and use this one instead. This one avoids the use
> of smaller slabs that cause the conflict. The first slab will be sized 32
> bytes instead of 8.

Thanks, I'll test it tomorrow.

> Note that I do not get why you would be aligning the objects to 32 bytes.
> Increasing the smallest cache size wastes a lot of memory. And it is
> usually advantageous if multiple related objects are in the same cacheline
> unless you have heavy SMP contention.

It's not about performance at all, it's about DMA buffers allocated
using kmalloc() getting corrupted. Imagine this:

1. A SPI protocol driver allocates a buffer using kmalloc()
2. SPI master driver receives a request and flushes all cachelines
touched by the buffer (using dma_map_single()) before handing it to
the DMA controller.
3. While the transfer is in progress, something else comes along and
reads something from a different buffer which happens to share a
cacheline with the buffer currently being used for DMA.
4. When the transfer is complete, the protocol driver will see stale
data because a part of the buffer was fetched by the dcache before the
received data was stored in RAM by the DMA controller.

Maybe there are other solutions to this problem, but the old SLAB
allocator did guarantee 32-byte alignment as long as SLAB debugging
was turned off, so setting ARCH_KMALLOC_MINALIGN seemed like the
easiest way to get back to the old, known-working behaviour.

It could be that I've underestimated the AVR32 AP cache though; I
think it can do partial writeback of cachelines, so it could be a
solution to writeback+invalidate the parts of the buffer that may have
shared cachelines from dma_unmap_*() and dma_sync_*_for_cpu(). It will
probably hit a few false positives since it might not always see the
whole buffer, but perhaps it's worth it.

Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/