[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [BUG] slab debug vs. L1 alignement
    Benjamin Herrenschmidt wrote:
    > Currently, when enabling slab debugging, we lose the property of
    > having the objects aligned on a cache line size.
    > This is, imho, an error, especially if GFP_DMA is passed. Such an
    > object _must_ be cache alined (and it's size rounded to a multiple
    > of the cache line size).
    > There is a simple performance reason on cache coherent archs, but
    > there's also the fact that it will just _not_ work properly on
    > non cache-coherent archs. Actually, I also have to deal with some
    > old machines who have a SCSI controller who has a problem accessing
    > buffers that aren't aligned on a cache line size boundary.
    > This is typically causing me trouble in various parts of SCSI which
    > abuses kmalloc(512, GFP_KERNEL | GFP_DMA) for buffers passed to some
    > SCSI commands, typically "utility" commands used to read a disk
    > capacity, read read/write protect flags, some sense buffers, etc...
    > While I know SCSI shall use the consistent alloc things, it has not
    > been fully fixed yet and kmalloc with GFP_DMA is still valid despite
    > not beeing efficient, so we should make sure in this case, the returned
    > buffer is really suitable for DMA, that is cache aligned.

    Attached untested patch should fix it (vs 2.6.0-test1), I've no
    idea if it's acceptable.

    Philippe Elie
    --- mm/slab.c~ 2003-07-14 03:36:48.000000000 +0000
    +++ mm/slab.c 2003-08-15 18:40:14.000000000 +0000
    @@ -682,7 +682,7 @@

    sizes->cs_dmacachep = kmem_cache_create(
    names->name_dma, sizes->cs_size,
    if (!sizes->cs_dmacachep)
     \ /
      Last update: 2005-03-22 13:47    [W:0.020 / U:1.580 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site