From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 05:03:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B4F5846; Mon, 24 Dec 2012 05:03:10 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCFC8FC0A; Mon, 24 Dec 2012 05:03:09 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id qBO4bkdW049692; Sun, 23 Dec 2012 21:37:46 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id qBO4bkEq049691; Sun, 23 Dec 2012 21:37:46 -0700 (MST) (envelope-from ken) Date: Sun, 23 Dec 2012 21:37:46 -0700 From: "Kenneth D. Merry" To: Adrian Chadd Subject: Re: 9.1 minimal ram requirements Message-ID: <20121224043746.GA49438@nargothrond.kdm.org> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: Marten Vijn , Sergey Kandaurov , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 05:03:10 -0000 The reason it grabs RAM up front is that it was written for an embedded platform where memory allocations might fail later on after things had been running and memory got fragmented. At this point, no, it doesn't need to allocate all of its memory up front. I actually need to put some effort into right-sizing the memory footprint, but that will take adding some fields to the path inquiry CCB so it knows what the capabilities of the target adapter are. (And that typically takes a CAM version bump, which breaks the ABI...) In any case, the memory footprint (and any possible side effects from the mpt driver with FC boards) are why I put the disable switch in. If there is memory allocated when it is disabled, then that is a bug. I'm on vacation so it'll be a little while before I'm in a position to fix this, but hopefully the disable switch should help anyone running with smaller amounts of memory. Ken On Sat, Dec 22, 2012 at 22:32:07 -0800, Adrian Chadd wrote: > Ken, > > Does CAM CTL really need to pre-allocate 35MB of RAM at startup? > > > > Adrian > > On 22 December 2012 16:45, Sergey Kandaurov wrote: > > On 23 December 2012 03:40, Marten Vijn wrote: > >> On 12/23/2012 12:27 AM, Jakub Lach wrote: > >>> > >>> Guys, I've heard about some absurd RAM requirements > >>> for 9.1, has anybody tested it? > >>> > >>> e.g. > >>> > >>> http://forums.freebsd.org/showthread.php?t=36314 > >> > >> > >> jup, I can comfirm this with nanobsd (cross) compiled > >> for my soekris net4501 which has 64 MB mem: > >> > >> from dmesg: real memory = 67108864 (64 MB) > >> > >> while the same config compiled against a 9.0 tree still works... > >> > > > > This (i.e. the "kmem_map too small" message seen with kernel memory > > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > > quite a big kernel memory consumer. > > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > > A longer term workaround could be to postpone those memory allocations > > until the first call to CTL. > > > > # cam ctl init allocates roughly 35 MB of kernel memory at once > > # three memory pools, somewhat under M_DEVBUF, and memory disk > > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > > > Type InUse MemUse HighUse Requests Size(s) > > devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 > > ctlmem 5062 10113K - 5062 64,2048 > > ctlblk 200 800K - 200 4096 > > ramdisk 1 4096K - 1 > > ctlpool 532 138K - 532 16,512 > > > > -- > > wbr, > > pluknet > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Kenneth Merry ken@FreeBSD.ORG