busdma dflt_lock on amd64 > 4 GB
sos at FreeBSD.ORG
Wed Oct 26 11:01:56 PDT 2005
On 26/10/2005, at 18:34, Jacques Caron wrote:
> I've looked around few drivers and there are quite a few different
> ways the API is used, and I'm not sure any is "correct" (see the
> ALLOCNOW and NO_WAIT used in many places). Having a reference
> implementation would be a good thing (tm).
> For instance, some drivers like ata create/allocate/load/whatever
> tags and maps for each request, while others prepare some of the
> stuff upon attach and only do the minimum at I/O time. That's
> probably better in terms of I/O performance but has the drawback
> that some memory might be wasted by unused or little-used devices.
> I'm sure the "guys who know" have an opinion on which option is
OK, lets take this apart for ATA.
ATA does all the tag/map creates/allocs/loads for the SGlist and
simple workspace stuff at channel attach time, there are NO further
creates or allocs after that. So that is exactly what I would expect
the ALLOCNOW flags to make busdma support, if that doesn't work
busdma needs to be fixed IMNHO.
Then when a request is sent to a device the data is
bus_dmamap_load'ed into place and unloaded when the resquest
finishes. It is not possible to have more than one request running on
a channel at a time.
This means I have no need for callbacks or anything, and they
actually wouldn't bring me anything but increased code complexity
which I dont need, in fact dont need at all.
I know this might change when tags get official support but it
doesn't bring anything but complexity there either (HINT: ATA has a
max of 32 tags).
Now, bounce buffers might be something entirely different, but I'd
expect the system to alloc at least one buffer of maxsize pr tag so
it has what it needs if and when. That might be a waste of memory but
for ATA its at max 128K pr channel, and that IMNHO is not a problem
sos at FreeBSD.org
More information about the freebsd-amd64