From owner-freebsd-hackers  Tue Oct 14 16:49:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA26985
          for hackers-outgoing; Tue, 14 Oct 1997 16:49:43 -0700 (PDT)
          (envelope-from owner-freebsd-hackers)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26979
          for <hackers@FreeBSD.ORG>; Tue, 14 Oct 1997 16:49:35 -0700 (PDT)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
	by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id QAA01650;
	Tue, 14 Oct 1997 16:49:23 -0700 (PDT)
Message-Id: <199710142349.QAA01650@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) 
In-reply-to: Your message of "Tue, 14 Oct 1997 16:51:43 EDT."
             <19971014165143.34402@ct.picker.com> 
Date: Tue, 14 Oct 1997 16:49:23 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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
>