From owner-cvs-all Mon Feb 17 11:39:16 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C668C37B401; Mon, 17 Feb 2003 11:39:14 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8725A43F75; Mon, 17 Feb 2003 11:39:13 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1HJd61o026808; Mon, 17 Feb 2003 11:39:06 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1HJd60O000834; Mon, 17 Feb 2003 11:39:06 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1HJd5iJ000833; Mon, 17 Feb 2003 11:39:05 -0800 (PST) Date: Mon, 17 Feb 2003 11:39:05 -0800 From: Marcel Moolenaar To: Andrew Gallatin Cc: Peter Wemm , "Alan L. Cox" , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c Message-ID: <20030217193905.GB593@athlon.pn.xcllnt.net> References: <3E500717.65436EAF@imimic.com> <20030217072612.577382A89E@canning.wemm.org> <15952.57680.522607.835422@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15952.57680.522607.835422@grasshopper.cs.duke.edu> User-Agent: Mutt/1.5.3i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 17, 2003 at 08:19:12AM -0500, Andrew Gallatin wrote: > > Peter Wemm writes: > > I believe we have bigger problems in the MI code.. we allocate the > > vm_page_t array to cover a linear range from the lowest entry in > > phys_avail to the highest entry address. This means that if we have > > machines that have 2G of ram at address 0 and another 2G at the 16G mark, > > then that means that the MI vm code allocates enough vm_page_t's in a > > linear array to to cover 18G of physical space. Needless to say, this > > That's exactly my situation. The alpha I'm porting to puts up to 16GB > of RAM per-cpu. So a 2 CPU system with nGB/cpu has a phys_avail that > looks like: {0,nGG,16GB,(16+n)GB}. Eg, a huge (16 - n)GB hole between > each CPU. This could eat a lot of memory on a 64-cpu box. > > BTW, I think I may have seen some autotuning issues with an 8GB box. > nbufs gets set to something absurd and an apparent infinate loop is > entered in vfs_bio.c, for example. Have you ia64 guys run with 8GB > yet? Not yet. We don't even get 2GB to work all the time due to sparseness :-) And ia64 is in the same position as alpha: busdma needs to be fixed. So we too have "collateral damage"... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message