From owner-freebsd-arch Fri Feb 23 15:48:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 58F7837B401 for ; Fri, 23 Feb 2001 15:48:38 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA09757; Fri, 23 Feb 2001 16:43:19 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA0LaObt; Fri Feb 23 16:43:11 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA01498; Fri, 23 Feb 2001 16:48:16 -0700 (MST) From: Terry Lambert Message-Id: <200102232348.QAA01498@usr05.primenet.com> Subject: Re: Memory Alloation from kernel loadable driver To: wainer@sandgate.com (Sue Wainer) Date: Fri, 23 Feb 2001 23:48:16 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG (Freebsd-Arch), jon@bigbang.com.au (Jon Wells) In-Reply-To: from "Sue Wainer" at Feb 23, 2001 12:44:02 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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