Messages in this thread | | | Date | Sat, 16 Aug 2003 14:21:22 +0300 (EEST) | From | Kai Makisara <> | Subject | Re: [BUG] slab debug vs. L1 alignement |
| |
On Sat, 16 Aug 2003, Benjamin Herrenschmidt wrote:
> > > > > > Hmm. That means slab debugging did it's job: The driver contains the > > wrong assumption that all pointers are cache line aligned. Without slab > > debugging, this would result in rare data corruptions in O_DIRECT apps. > > With slab debugging on, it's exposed immediately. > > As we discussed on IRC, I think SCSI host drivers (at least) can assume > beeing passed aligned buffers, if somebody don't agree, please speak > up ;) Christoph said that O_DIRECT has strict alignement rules too. > A character device (like st) doing direct i/o from user buffer to/from a SCSI device does not currently have any alignment restrictions. I think restricted alignment can't be required from a user of an ordinary character device. This must then be handled by the driver. The solution is to use bounce buffers in the driver if the alignment does not meet the lower level requirements. This leads to surprises with performance if the user buffer alignment does not satisfy the requirements (e.g., malloc() may or may not return properly aligned blocks). These surprises should be avoided as far as the hardware allows.
If an architecture has restrictions, they must, of course, be taken into account. However, this should not punish architectures that don't have the restrictions. Specifying that DMA buffers must be cache-line aligned would be too strict. A separate alignment constraint for DMA in general and for a device in specific would be a better alternative (a device may have tighter restrictions than an architecture). The same applies to buffer sizes. This would mean adding two more masks for each device (like the current DMA address mask for a device).
-- 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/
| |