busdma dflt_lock on amd64 > 4 GB

[Søren Schmidt]

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  
> better.

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  
today..

Søren Schmidt
sos at FreeBSD.org