Date: Tue, 14 Oct 1997 16:51:43 -0400 From: Randall Hopper <rhh@ct.picker.com> To: julian@whistle.com Cc: hackers@freebsd.org Subject: LKM & Large contig malloc failure (Re: lkms versus hard linked drivers) Message-ID: <19971014165143.34402@ct.picker.com>
next in thread | raw e-mail | index | archive | help
Julian Elischer: |mdean wrote: |> My question is very simple: What can't be a lkm? | |the only function that MUST be done at bootup is allocation of LARGE |physically contiguous buffers of ram. because after running a few |seconds ram get's fragmented.. large VIRTUALLY contiguous buffers are |ok. That explains it. I just spent some time LKMizing the Brooktree (bktr) PCI capture driver to speed up development, only to find last night that vm_page_alloc_contig would just hang, whittling away swap and consuming 50% CPU with no end in sight. The driver is one of the few that does large contiguous mallocs (first a 32K bite; then a 3.5Meg gulp). Searching the list archives for tips, I happened upon your post. What's the best way around this? Have a dummy "grab the memory" stub driver that runs on bootup, and then have the real driver in the LKM "borrow" this memory chunk away when it loads. Not real clean, so this would of course just be a "for-development-only" hack. Would sure be nice to make the driver generally available as an LKM though. Can anyone see a cleaner way around this problem? Thanks, Randall Hopper
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971014165143.34402>