Date: Fri, 24 Mar 2000 00:18:43 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: scsi@FreeBSD.ORG Subject: Re: bus_dmamap_load() and boundaries Message-ID: <Pine.LNX.4.10.10003232337220.2139-100000@linux.local> In-Reply-To: <200003221814.LAA09815@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Mar 2000, Justin T. Gibbs wrote:
> In article <Pine.LNX.4.10.10003210050130.284-100000@linux.local> you wrot=
e:
> >=20
> > Hello,
> >=20
> > Due to errata, some SYMBIOS chip revisions require scatter entries not =
to
> > cross 16 MB boundaries. I can tell bus_dma_tag_create() about a
> > `boundary', but this parameter does not seem to apply to bus physical
> > scattered chunks returned by bus_dmamap_load(). This parameter seem to
> > only apply to memory allocated using bus_dmamem_alloc().
> >=20
> > Is this the expected behaviour or am I missing something?
>=20
> Boundary support in bus_dmamap_load() just hasn't been implemented yet.
Ok. Thanks for the reply.
> It shouldn't be too hard to add.
Indeed. But, for now, latest `sym' handles this situation by itself. Btw,
on i386 the additon of boundary checking inside the scattering loop
increases register pressure and resulted machine code is pathetic. I would
also suggest to add the option of not actually trying coalescing physical
adjacent pages if boundary is just page aligned, and implement 3 different
loops:
1) Scatter with page boundary
2) Scatter with coalescing but no boundary checking (current)
3) Scatter with coalescing and boundary checking.
(1) is about 10 instructions per loop on i386
(2) should still be reasonnable
(3) should take more than 30 instructions per loop with great register=20
pressure on i386.
(May-be I am just nitpicking there :) )
I have another suggestion. BSD systems provide a single virtual buffer to
SIMs. In result, actual IOs are smaller that they could be if providing
a list of virtual buffer was possible, since IO coalescing would be a lot
simpler to implement from upper layers.
My suggestion is to support some new extended bus_dmamap_load service that
accept a scattered list of virtual buffers as input, as CAM specification
seem to allow. Enhancement of upper layers could come later. (By the way,
as you know, for example, Linux SCSI drivers are provided by such
scatterlists of virtual buffers).
With modern hard disks that are very fast, providing too small IOs in
average could get very sub-optimal. My opinion is that coalescing IOs when
possible is much more important for performances than sorting them with
Ultra-160 (and why with not future Ultra 320) hard disks. Note that
maintaining lists of sorted IOs helps for IO coalescing.
G=E9rard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10003232337220.2139-100000>