[lkml]   [2007]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kernel BUG at mm/slub.c:3689!
    On 6/11/07, Christoph Lameter <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-11 20:25    [W:0.022 / U:10.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site