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

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 10/07/03

  • Next message: Greg 'groggy' Lehey: "Re: Alignment of disk-I/O from userland." 
    To: Scott Long <scottl@freebsd.org>
Date: Tue, 07 Oct 2003 01:11:11 +0200

    In message <20031006163218.L55190@pooker.samsco.home>, Scott Long writes:

    >We already
    >have the busdma interface whose sole purpose is to take system
    >buffers and prepare them for transfer to/from hardware [...]

    I certainly do agree that _if_ we do want to do copy/align busdma would
    be a good place for it.

    >As for returning an error code for a buffer that we (arbitrarily) believe
    >to be too big to align, [...]

    I have never advocated returning an error based on "alignment and size",
    only based on alignment alone.

    But I also just realized a complication I had not thought of earlier,
    and which may modify our thinking further: This is an issue for
    all physread()/physwrite() drivers, not just disks.

    In other words, if I want to write to 1MB blocks to a SCSI tape,
    and I don't align my in memory buffer sufficiently for the hardware,
    busdma would have to allocate 1MB of memory (it may _possibly_ be
    able to do so as disjunct pages rather than consequtively) and copy
    the entire request over.

    For disks we can chop the request at sector boundaries or multiple
    thereoff and deal with it that way, but we don't have that option
    for scsi_sa or even scsi_pt devices.

    Currently we impose a 128k upper limit on I/O requests, but we have
    already more or less agreed that needs to grow into the 4-16MB range
    soon.

    The more I think about it, there more arguments I find for retaining
    the status quo of requiring userland to do proper alignment (but
    with better error-checking).

    Particularly since the only unaligned case I know of yet, newfs(8),
    is by trivial accident rather than need or intent.

    The question of how to communicate the alignment required to
    userland has been raised. I propose this answer:

        Suffient alignment can be obtained by any one of these methods:
            1. Allocate your buffer with malloc(3).
            2. Align it to the request size.
            3. Align it to a page.

    (The first is somewhat dependent on the behaviour of phkmalloc, and
    can be removed, but it offers a nice clean shortcut for most
    programmers.) 

    -- 
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"
  • Next message: Greg 'groggy' Lehey: "Re: Alignment of disk-I/O from userland."

    Relevant Pages

    • Re: Alignment of disk-I/O from userland.
      ... >>alignment of data buffers used to access disk devices directly. ... > of this by copying the request as necessary. ... How are we going to express the alignment requirements to the upper ...
      (freebsd-arch)
    • Re: (FWD) Serious busdma bug in -current in relation to USB harware.
      ... Why original data alignment should so ... strictly affect hardware operation? ... I see no other way around this than to change busdma. ...
      (freebsd-current)
    • Re: Patch: sym(4) "VTOBUS FAILED" panics on amd64, amd64/89550
      ... busdma supports alignment constraints; why not just set ... I realize sym has its own ... busdma can take care of easily. ... I've been the co-author of the ncr SCSI driver, ...
      (freebsd-stable)
    • Re: non aligned DMA transfer attempted
      ... The ATA driver does not use ... His answer is short, but correct, because all ATA drivers do use BUSDMA. ... The CAM passthrough doesn't care a whole lot about alignment because alignment is the concern of the SIMs in conjunction with busdma, not the periph and transport layers of CAM. ... The vast majority of the storage drivers in the tree use busdma and use it correctly for deferred loads. ...
      (freebsd-current)
    • 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)
    • Quantcast