busdma dflt_lock on amd64 > 4 GB
jc at oxado.com
Wed Oct 26 09:57:28 PDT 2005
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 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):
> There are also ample examples in the source tree, with the only
>incorrect ones being those that are no longer popular enough to warrant
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.
More information about the freebsd-amd64