Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 16 Aug 2003 03:47:39 +0200 | From | Manfred Spraul <> | Subject | Re: [BUG] slab debug vs. L1 alignement |
| |
Benjamin Herrenschmidt wrote:
>On Fri, 2003-08-15 at 23:50, Manfred Spraul wrote: > > >>Ben wrote: >> >> >> >>>Currently, when enabling slab debugging, we lose the property of >>>having the objects aligned on a cache line size. >>> >>> >>> >>> >>Correct. Cache line alignment is advisory. Slab debugging is not the >>only case that violates the alignment, for example 32-byte allocations >>are not padded to the 128 byte cache line size of the Pentium 4 cpus. I >>really doubt we want that. >> >> > >Yes, I understand that, but that is wrong for GFP_DMA imho. Also, >SLAB_MUST_HWCACHE_ALIGN just disables redzoning, which is not smart, >I'd rather allocate more and keep both redzoning and cache alignement, >that would help catch some of those subtle problems when a chip DMA >engine plays funny tricks. > I don't want to upgrade SLAB_HWCACHE_ALIGN to SLAB_MUST_HWCACHE_ALIGN depending on GFP_DMA: IIRC one arch (ppc64?) marks everything as GFP_DMA, because all memory is DMA capable.
Which arch do you use? Perhaps alignment could be added for broken archs.
Actually I think you should fix your arch, perhaps by double buffering in pci_map_ if the input pointers are not aligned. What if someone uses O_DIRECT with an unaligned pointer?
-- Manfred
- 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/
| ![\](/images/icornerr.gif) |