lkml.org 
[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.038 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site