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

From: Jeff Roberson (jroberson_at_chesapeake.net)
Date: 10/07/03

  • Next message: Scott Long: "Re: Alignment of disk-I/O from userland."
    Date: Mon, 6 Oct 2003 18:43:47 -0400 (EDT)
    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.
    >
    > All in all, I would advocate that we decide that disks in FreeBSD
    > are allowed to return ENXIO if they get insufficiently aligned
    > requests.

    This could break things like cat, grep, strings, etc. except that they
    probably malloc sufficiently large chunks to get their own page, or at
    least heavily aligned data due to the properties of power of two
    allocators. I would be awfully sad if we broke the notion of character
    devices being regular files though.

    How are we going to express the alignment requirements to the upper
    layers? Does busdma provide this now? If not, do we know which devices
    have these requirements?

    I think that we should provide the bouncing purely for POLA. I doubt any
    software that ships with FreeBSD will need it so there should be no
    performance issues in practice.

    >
    > --
    > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
    > phk@FreeBSD.ORG | TCP/IP since RFC 956
    > FreeBSD committer | BSD since 4.3-tahoe
    > Never attribute to malice what can adequately be explained by incompetence.
    > _______________________________________________
    > 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"
    >

    _______________________________________________
    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: Scott Long: "Re: Alignment of disk-I/O from userland."

    Relevant Pages

    • Re: realloc() implicit free() ?
      ... a zero block size as a request for one byte, and let the alignment mechanisms raise it as they will. ... but the Standard does not require the allocated object to ... The compiler system does. ...
      (comp.lang.c)
    • Re: How does malloc align pointer
      ... A request for two bytes of storage might only be ... >>> that even though the CPU might require 4 or 8 byte alignment ... >>The standard requires a non-null return from malloc() to be appropriately ... Lawrence ...
      (comp.lang.c)
    • Re: Alignment of disk-I/O from userland.
      ... I certainly do agree that _if_ we do want to do copy/align busdma would ... I have never advocated returning an error based on "alignment and size", ... For disks we can chop the request at sector boundaries or multiple ... the status quo of requiring userland to do proper alignment (but ...
      (freebsd-arch)
    • Re: realloc() implicit free() ?
      ... >> zero block size as a request for one byte, and let the alignment ... > but the Standard does not require the allocated object to have ...
      (comp.lang.c)

  • Quantcast