busdma dflt_lock on amd64 > 4 GB

[Jacques Caron]

Hi again Scott,

At 17:48 26/10/2005, Scott Long wrote:
>All ALLOCNOW does is guarantee that there are enough bounce pages 
>for one consumer of the bounce zone to succeed.  Bounce pages are 
>pooled into zones that correspond to similar  attributes.  If you create a
>bunch of tags that have similar attributes, then they'll map to the
>same zone and you won't necessarily get more pages pre-allocated to
>that zone.  Not well documented, I know.  The justification for this
>behaviour is to prevent excessive amounts of RAM from being reserved
>by careless drivers.  The pools can grow when maps are created, though.

As stated in my other post, if I undertand the busdma code correctly, 
additional pages will not be allocated if ALLOCNOW was set unless 
it's an additional map on the same tag. So the first map on a tag 
will not get any additional pages, and if other tags (created by 
other instances of the same driver, thus hitting the same bounce 
zones) have already used all pre-allocated pages, no more pages will 
be allocated, and hence a deferral happens even though the number of 
bounce pages is still very low and way way lower than maxpages.

>As for the callbacks, you're already using them.

They are used, but in a minimalist way, the rest of the processing is 
not deferred until the callback is called, this may require quite a 
bit more work.


>Re-arranging the code to use it
>correctly is not hard, and I've published a number of pieces on how to
>do it.

Do you have pointers? I've been looking quite a bit for documentation 
about bus_dma, and it's quite scattered and (in my opinion) 
incomplete. Actually the place I found that was most descriptive is 
in the ISA device driver chapter of the "architecture handbook" 
(which I can't find on the FreeBSD site):

http://freebsd.active-venture.com/arch-handbook/isa-driver-busmem.html

>   There are also ample examples in the source tree, with the only
>incorrect ones being those that are no longer popular enough to warrant
>the work.

I didn't think ata was unpopular :-)

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.

Thanks,

Jacques.