From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 15:29:03 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF12337B401 for ; Thu, 10 Apr 2003 15:29:03 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E4143F3F for ; Thu, 10 Apr 2003 15:29:03 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3AMTXxS093071; Thu, 10 Apr 2003 18:29:33 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3AMTXiu093070; Thu, 10 Apr 2003 18:29:33 -0400 (EDT) Date: Thu, 10 Apr 2003 18:29:32 -0400 From: Jake Burkholder To: Anders Andersson Message-ID: <20030410222932.GN78831@locore.ca> References: <20030410220149.GA3168@gw.andersa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410220149.GA3168@gw.andersa.net> User-Agent: Mutt/1.4i cc: sparc64@FreeBSD.org Subject: Re: sparc64 real memory X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2003 22:29:04 -0000 Apparently, On Fri, Apr 11, 2003 at 12:01:49AM +0200, Anders Andersson said words to the effect of; > Hi Jake, > > One question comes to mind after your latest commit to fix the 'real > memory' report in dmesg on sparc64. > > I have 512MB of RAM in both my i386 (p4) box and in my Ultra10. > > sparc64: > real memory = 515129344 (491 MB) > avail memory = 493608960 (470 MB) > > i386: > real memory = 536805376 (511 MB) > avail memory = 516767744 (492 MB) > > Is this difference something one would pay any notice about or is ot > normal? Its normal. The real memory will be lower because the prom takes a chunk of memory and we can't reclaim it for the kernel because we still need to call the prom. There may be some stuff that we're not reclaiming from the loader, but its a little unclear how to safely do that. The avail memory will be lower in relation to the real memory due to being a 64 bit platform; everything is just bigger. Jake