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

> Have you looked at pci_pool_{create,alloc,free,destroy}? The functions
> were specifically written to provide aligned buffers for DMA operations.
> Perhaps SCSI should use them?

Of course it should, but it doesn't yet. And other drivers haven't been
ported yet neither though that is slowly happening. Still, I think the
point that a GFP_DMA should be cache aligned still stands, don't you
think ?

Ben.

-
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.061 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site