Alignment of disk-I/O from userland.

Scott Long scottl at freebsd.org
Mon Oct 6 15:44:18 PDT 2003


On Mon, 6 Oct 2003, Poul-Henning Kamp wrote:
> In message <200310062146.h96Lkpx0093486 at 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


More information about the freebsd-arch mailing list