Date: Mon, 06 Oct 2003 20:33:15 -0600 From: Scott Long <scottl@freebsd.org> To: Don Lewis <truckman@FreeBSD.org> Cc: wollman@khavrinen.lcs.mit.edu Subject: Re: Alignment of disk-I/O from userland. Message-ID: <3F8225EB.5020902@freebsd.org> In-Reply-To: <200310070049.h970mvN1052990@gw.catspoiler.org> References: <200310070049.h970mvN1052990@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F8225EB.5020902>