Date: Fri, 23 Feb 2001 23:48:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wainer@sandgate.com (Sue Wainer) Cc: freebsd-arch@FreeBSD.ORG (Freebsd-Arch), jon@bigbang.com.au (Jon Wells) Subject: Re: Memory Alloation from kernel loadable driver Message-ID: <200102232348.QAA01498@usr05.primenet.com> In-Reply-To: <NDBBLIBAPKIAHMINJJNFIEJFCEAA.wainer@sandgate.com> from "Sue Wainer" at Feb 23, 2001 12:44:02 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I have a pci driver which is loaded using kldload. It is allocating a no. of > pages by calling vm_page_alloc_contig. > This convention is used by other pci drivers, though not necessarily > loadable ones. > > On machines without much memory, or ones with more memory but having done > compilations prior to kldloading, > contigmalloc1 gets stuck in a continuous loop looping from the first "goto > again1." There is a comment > above configmalloc1 which might imply that this contiguous allocation does > not work after initialization. > > For locked-down memory, what allocation routines should loadable drivers be > calling? Is there any source of > documentation of memory allocation which could be of value? The classic answer to this is to load you driver as part of the boot process, perhaps even having it in the list of things loaded by the boot loader, to ensure that sufficient contiguous memory is available for it. Theoretically, it's possible to defragment the kernel page map in order to free up contiguous physical memory, and it is not in practice too hard, so long as your defragmenter does not touch the pages it references. The task is a little more complex for things like shared memory objects, since you have to deal with the process page maps as well. It's also somewhat complicated by the agressive caching of clean pages. The easiest thing to do is to copy the pages around, and allocate the original pages to the contiguous zone being created atomically, rather than freeing the pages back to the system. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102232348.QAA01498>