lkml.org 
[lkml]   [2003]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] slab debug vs. L1 alignement
From
Date
Perhaps we should remind ourselves what the alignment rules actually are
for kmalloc:

1) No two kmalloc allocations may share cache lines (otherwise data
corruption will result).
2) kmalloc should be on a power of two alignment consistent with the
widest processor data access requirements.

Now note that 1) is optional (but an efficiency speed up) for a coherent
architecture. It is an *absolute requirement* for a non-coherent
architecture.

2) is essentially what's causing Ben the problems. His driver appears
to be insisting that DMA be a full PCI cache line width. I can see
arguments for making this a driver problem.

However, as far as the redzoning issue goes, I think in order to avoid
cache line interference, the redzone should be sized to be a cache line
width, at least on non-coherent architectures.

In theory, the above should solve everyone's problems.

As far as I/O from user land goes (especially to tape), the users
usually can work out the alignment constraints and act accordingly. I'm
agnostic as to whether we should fail (with an error indicating
alignment problems) or rebuffer causing inefficiency in throughput in
the misaligned case.

James



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