From owner-freebsd-performance@FreeBSD.ORG Mon May 5 21:09:55 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 250FC37B401 for ; Mon, 5 May 2003 21:09:55 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CB5743FA3 for ; Mon, 5 May 2003 21:09:54 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Ctm3-0003k6-00; Mon, 05 May 2003 21:09:52 -0700 Message-ID: <3EB7353F.373470F2@mindspring.com> Date: Mon, 05 May 2003 21:08:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Anderson References: <3801.172.182.185.39.1052141430.squirrel@bluhayz.homeunix.org> <3EB6A981.1030504@centtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4426e50e378b293f1d616dcb351543252548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: freebsd-performance@freebsd.org cc: Kyle Rollin Subject: Re: Real and availible RAM X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 04:09:55 -0000 Eric Anderson wrote: > > If you look at the way x86 architecture is designed (and somebody else can > > feel free to correct me if I'm wrong), but system memory is often used in > > the caching/shadowing of BIOS. This is where a lot of system memory often > > goes before the OS is loaded - also, as Rob said, the kernel itself will > > take up memory before the rest of the OS is booted. > > I believe that the BIOS steals the ram prior to the OS booting, so that > the box does not show that as part of the total ram.. Like: Since the BIOS is where FreeBSD obtains the "real memory" number, this is pretty unlikely; the BIOS would just lie to FreeBSD about the number, and be done with it. Also, the 6M is the FreeBSD kernel, page tables, and some misc stuff. You'll note that the "real memory" number is smaller than the expected number for the amount of physical RAM: it already contains the lies by the BIOS. Basically, FreeBSD does not retroactively repair the accounting of the VM system to account for memory consumed before it was up and running -- e.g. it uses pages, and it (in fact) loses pages as well (for example the pages used for the 4K page tables for the kernel prior to the switch over to 4M pages, if you switch to 4M pages, are never returned to the VM system, among many others). The "real" vs. "avail" are a courtesy, between what FreeBSD was told by the BIOS, vs. what is known to the FreeBSD VM. I really suggest anyone who thinks any differently read and understand the code in /sys/i386/i386/machdep.c; specificfically, getmemsize(), where "basemem", "extmem", and Maxmem are calculated, and in the code that gets run in cpu_startup() that prints out the "avail" from ptoa(cnt.v_free_count) -- the VM system's idea of the size of memory available to the kernel. -- Terry