Re: Alignment of disk-I/O from userland.

From: Scott Long (scottl_at_freebsd.org)
Date: 10/07/03

  • Next message: Poul-Henning Kamp: "Re: Alignment of disk-I/O from userland."
    Date: Mon, 6 Oct 2003 16:44:32 -0600 (MDT)
    To: Poul-Henning Kamp <phk@phk.freebsd.dk>
    
    

    On Mon, 6 Oct 2003, Poul-Henning Kamp wrote:
    > In message <200310062146.h96Lkpx0093486@khavrinen.lcs.mit.edu>, Garrett Wollman
    > writes:
    >
    > >I think that gives us plenary authority to require appropriate
    > >alignment of data buffers used to access disk devices directly.
    >
    > Well, apart from us wedging or botching the request rather than
    > return a consistent error we're standards compliant then.
    >
    > It has been mentioned on #thatchannel that busdma should take care
    > of this by copying the request as necessary. Faced with the prospect
    > of a request several megabytes in size, I don't like the prospect
    > of malloc/bcopy too much.

    Working around hardware requirements from the block layer gets messy.
    You obviously don't want to manually align buffers that are distined
    for hardware that doesn't care about the alignment. How do you
    communicate this property upwards from the driver? Callbacks? Extra
    flags in disk_create()? It's all rather messy that way. We already
    have the busdma interface whose sole purpose is to take system
    buffers and prepare them for transfer to/from hardware. It already
    understands the concept of alignment, though it only applies it to
    buffers that it allocates, not buffers that are handed to it. Fixing
    that would be easy, and would allow for optimizations based on the
    bus (GART and IOMMU remapping). It also keeps the property down at
    the device driver where it belongs.

    As for returning an error code for a buffer that we (arbitrarily) believe
    to be too big to align, I'm not sure that it's a valid thing to worry
    about. People expect their hardware to Just Work, regardless of how cheap
    it is. If someone buys a cheap card with a cheap DMA engine, their cost
    comes in from higher system time per I/O. If they don't like that, they
    can complain to the manufacturer and/or buy a better card. I'm not aware
    of Linux nor OSX rejecting I/O based on arbitrary size limits.

    Scott
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  • Next message: Poul-Henning Kamp: "Re: Alignment of disk-I/O from userland."

    Relevant Pages

    • 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: [BUG] slab debug vs. L1 alignement
      ... >> With slab debugging on, ... > beeing passed aligned buffers, if somebody don't agree, please speak ... SCSI device does not currently have any alignment restrictions. ... Specifying that DMA buffers must be cache-line aligned would ...
      (Linux-Kernel)
    • 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: DeviceIoControl failed in WOW64 on 64bit XP Pro
      ... >> Alignment can be an issue. ... Align all IOCTL buffers on 8 bytes. ... I understand that you are not passing any pointers... ... 64-bit alignment of IRP buffers before they check anything else. ...
      (microsoft.public.development.device.drivers)
    • Re: [PATCH] e100 rx: or s and el bits
      ... S-bit patch work in that no corruption seemed to occur over long term runs. ... If I use the default settings for CPU saver and drop the receive pool down to 16 buffers I can cause problems with various forms of the patch. ... Hardware consumes 3 buffers ...
      (Linux-Kernel)