Date: Mon, 17 Feb 2003 08:19:12 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@wemm.org> Cc: "Alan L. Cox" <alc@imimic.com>, Marcel Moolenaar <marcel@xcllnt.net>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c Message-ID: <15952.57680.522607.835422@grasshopper.cs.duke.edu> In-Reply-To: <20030217072612.577382A89E@canning.wemm.org> References: <3E500717.65436EAF@imimic.com> <20030217072612.577382A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15952.57680.522607.835422>