Date: Tue, 14 Oct 1997 16:49:23 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: LKM & Large contig malloc failure (Re: lkms versus hard linked drivers) Message-ID: <199710142349.QAA01650@rah.star-gate.com> In-Reply-To: Your message of "Tue, 14 Oct 1997 16:51:43 EDT." <19971014165143.34402@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Your approach is probably the quickest way of solving the problem. Cheers, Amancio >From The Desk Of Randall Hopper : > 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?199710142349.QAA01650>