Date: Thu, 23 Mar 2000 18:41:49 -0700 From: "Justin T. Gibbs" <gibbs@FreeBSD.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@FreeBSD.ORG Subject: Re: bus_dmamap_load() and boundaries Message-ID: <200003240141.SAA44379@caspian.plutotech.com> In-Reply-To: Your message of "Fri, 24 Mar 2000 00:18:43 %2B0100." <Pine.LNX.4.10.10003232337220.2139-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Boundary support in bus_dmamap_load() just hasn't been implemented yet=
=2E
>
>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.
Hmm. Not that I've tested it, but the boundary checking that I added
increased the size of of the entire busdma_machdep.o file by 64 bytes.
I'm no x86 guru, but I can't believe that too much register spilling
occurred with only 64 bytes worth of instruction space increase. Here's
the code:
if (sg->ds_len =3D=3D 0) {
sg->ds_addr =3D paddr;
sg->ds_len =3D size;
} else if (paddr =3D=3D nextpaddr
=3D=3D> && (((paddr - 1) ^ (paddr - 1 + size))
=3D=3D> & ~(dmat->boundary - 1)) =3D=3D 0) {
sg->ds_len +=3D size;
} else {
/* Go to the next segment */
Of course this does nothing for alignment checking which should
also be fixed. I'd have to think a bit to come up with something
efficient for boundaries < PAGE_SIZE.
>I would
>also suggest to add the option of not actually trying coalescing physica=
l
>adjacent pages if boundary is just page aligned, and implement 3 differe=
nt
>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
Isn't this the same as specifying a maxseg size of PAGE_SIZE?
Unfortunately it looks like I failed to honor the maxseg size
parameter in this code. Oops.
>(2) should still be reasonnable
>(3) should take more than 30 instructions per loop with great register =
> pressure on i386.
>
>(May-be I am just nitpicking there :) )
It seems to me that having the hardware fetch an extra S/G segment
over the PCI bus must be less efficient than the CPU overhead to
coalless contiguous segments. Maybe I'm wrong though.
>I have another suggestion. BSD systems provide a single virtual buffer t=
o
>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 lo=
t
>simpler to implement from upper layers.
This is likely to happen sometime this year. struct buf is going away
and we have talked for several years about having some type of chained
I/O.
>My suggestion is to support some new extended bus_dmamap_load service th=
at
>accept a scattered list of virtual buffers as input, as CAM specificatio=
n
>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).
If we follow the NetBSD way, there will be bus_dmamap_load interfaces
for most popular I/O structures (UIO, mbuf, etc.). Bus DMA just hasn't
been fully developed yet.
>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 wh=
en
>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.
Getting larger I/Os should be as simple as changing the clustering
parameters in the filesystem clustering code. Unfortunately, too
many interfaces are tied to struct buf and that will have to be
fixed before I/O sizes can be increased much.
--
Justin
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?200003240141.SAA44379>