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, 06 Oct 2003 20:33:15 -0600
To: Don Lewis <truckman@FreeBSD.org>

    Don Lewis wrote:
    > On 7 Oct, Poul-Henning Kamp wrote:
    >
    >
    >>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.
    >
    >
    > There might be another reason to other than alignment to copy the data.
    > What are the limits on the size of the scatter-gather lists that are
    > supported by the DMA engines of commonly available controllers? It is
    > unlikely that the user's buffer will be in contiguous memory even if it
    > is properly aligned. It might be necessary to copy the the memory into
    > some number of buffers, where each buffer is in contiguous physical
    > memory, so that reasonable size I/O requests can be supported on
    > commonly available controllers. A 4MB request might require 1K
    > scatter-gather list entries on a machine with a 4K page size. Ick ...
    >

    This again is a job for busdma. Again, it isn't implemented, but the
    API details are already defined and waiting for the back-end code. With
    more and more drivers switching to busdma, it really makes much more
    sense to finish the implementation there rather than invent several new
    implementations elsewhere.

    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: [Lit.] Buffer overruns
      ... of physical memory. ... >Overrun in that case was having the bits in a buffer spill over ... >I, an app program, request 100K core from the monitor. ... >>associate the cryptic error message with what they've done wrong. ...
      (sci.crypt)
    • Re: Alignment of disk-I/O from userland.
      ... > all physread/physwritedrivers, not just disks. ... > the entire request over. ... unlikely that the user's buffer will be in contiguous memory even if it ...
      (freebsd-arch)
    • RE: Strange MDL behavior
      ... Since I am in an IRP_MJ_READ request I am expected to write to the ... memory is not mapped to virtual memory yet, so no other thread can write to ... buffer in stead of passing the request on to the disk driver. ... differs = FALSE; ...
      (microsoft.public.win32.programmer.kernel)
    • Re: When to check the return value of malloc
      ... and works on all legitimate size requests, if memory is, in fact, ... request that could exceed the range of an int. ... not too long back - allocation requests exceeding the range of an int ... little less efficiently, with a smaller buffer. ...
      (comp.lang.c)
    • [NT] Vulnerability Report for Windows SMB DoS
      ... cross-platform mechanism for client systems to request file services from ... In order to exploit the vulnerability a user account is needed for the ... is therefore vulnerable to a denial of service attack. ... Later in the processing of the request, at SRV.SYS+33209h another buffer ...
      (Securiteam)