Messages in this thread | | | Date | Mon, 18 Aug 2003 23:29:51 +0300 (EEST) | From | Kai Makisara <> | Subject | Re: [BUG] slab debug vs. L1 alignement |
| |
On Sun, 17 Aug 2003, James Bottomley wrote:
... > 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. > I think we should rebuffer so that we don't fail writes and reads that other systems can do.
However, I am not so optimistic about the users aligning the buffers. According to the info, glibc aligns at 8 bytes or 16 bytes (64 bit architectures). I made st fail writes if the test
#define ST_DIO_ALIGN_OK(x) \ (((unsigned long)(x) & (L1_CACHE_BYTES - 1)) == 0)
fails on the buffer address. With a P4 kernel the result was that tar to tape failed ;-(
A solution would be to define the address test for user buffers based on the configuration, for example:
#if defined(CONFIG_XXX) #define ST_DIO_ALIGN_OK(x) \ (((unsigned long)(x) & (L1_CACHE_BYTES - 1)) == 0) #elif defined(CONFIG_YYY) #define ST_DIO_ALIGN_OK(x) \ (((unsigned long)(x) & 7) == 0) #else #define ST_DIO_ALIGN_OK(x) (1) #endif
Of course, it would be better if this would be defined in a more general place than st.c (some scsi header, dma-mapping.h, ... ?).
-- Kai - 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/
| |