Re: [BUG] slab debug vs. L1 alignement

[Manfred Spraul]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/