From owner-cvs-all Mon Feb 17 5:19:23 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 DFE6D37B401; Mon, 17 Feb 2003 05:19:21 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0654743FA3; Mon, 17 Feb 2003 05:19:19 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h1HDJH8I013609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 Feb 2003 08:19:17 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h1HDJC342850; Mon, 17 Feb 2003 08:19:12 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15952.57680.522607.835422@grasshopper.cs.duke.edu> Date: Mon, 17 Feb 2003 08:19:12 -0500 (EST) To: Peter Wemm Cc: "Alan L. Cox" , Marcel Moolenaar , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c In-Reply-To: <20030217072612.577382A89E@canning.wemm.org> References: <3E500717.65436EAF@imimic.com> <20030217072612.577382A89E@canning.wemm.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 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? I'm not going to worry about it too much just yet, as I need to set MAXMEM to 1GB anyway because alpha's busdma support is incomplete. (as is the busdma support for if_dc, which is what I'm booting from..). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message