Re: [BUG] slab debug vs. L1 alignement

From: Kai Makisara (Kai.Makisara_at_kolumbus.fi)
Date: 08/16/03

  • Next message: Tomas Szepe: "Re: Centrino support" 
    Date:	Sat, 16 Aug 2003 14:21:22 +0300 (EEST)
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>

    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/
  • Next message: Tomas Szepe: "Re: Centrino support"

    Relevant Pages

    • Re: [BUG] slab debug vs. L1 alignement
      ... > SCSI device does not currently have any alignment restrictions. ... This must then be handled by the driver. ... Specifying that DMA buffers must be cache-line aligned would ...
      (Linux-Kernel)
    • Re: Handling high UDP throughput
      ... The product that uses this sustains 540MbS with a 38kHz interrupt running using more than half the processor's power, so a lot goes on in the system but a lot of time is available for TCP/IP. ... The Ethernet driver was optimized, the memory movement was optimized (just using an inline memcpy that does a DMA transfer adds 30% to the effective speed), the IP checksum was in assembly, and a zero-copy TCP/IP stack was required. ... How much TX buffers did you have? ...
      (comp.arch.embedded)
    • Re: 1394 and Vista64
      ... I had my fair amount of aggravation running dma above 4Gb. ... I had some success forcing all buffers that took place in a dma to ... I dislike the idea of bounce buffers, but the alternative in my case ... Say it's a dma to the chip: ...
      (microsoft.public.development.device.drivers)
    • Re: Alignment of disk-I/O from userland.
      ... SL>>>alignment of data buffers used to access disk devices directly. ... SL>Working around hardware requirements from the block layer gets messy. ... SL>communicate this property upwards from the driver? ...
      (freebsd-arch)
    • Re: complement to sendfile()?
      ... DMA engine in the chipset. ... copies from the mbufs direct to user buffers asynchronously, ... This is because network buffers can be made ...
      (freebsd-net)