Date: Wed, 26 Oct 2005 18:34:57 +0200 From: Jacques Caron <jc@oxado.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-amd64@FreeBSD.ORG, Søren Schmidt <sos@FreeBSD.ORG> Subject: Re: busdma dflt_lock on amd64 > 4 GB Message-ID: <6.2.3.4.0.20051026180325.03ad7558@wheresmymailserver.com> In-Reply-To: <435FA542.3030209@samsco.org> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> <435FA542.3030209@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.3.4.0.20051026180325.03ad7558>