From: Simen Thoresen <simentt@dolphinics.no>
To: gmu 2k6 <gmu2006@gmail.com>
Cc: Joel Jaeggli <joelja@uoregon.edu>, linux-kernel@vger.kernel.org
Subject: Re: Only 3.2G ram out of 4G seen in an i386 box
Date: Thu, 10 Aug 2006 23:09:02 +0200 [thread overview]
Message-ID: <44DBA06E.40104@dolphinics.no> (raw)
In-Reply-To: <f96157c40608090754m1f10e0f2h5fbf3b256d2e55e1@mail.gmail.com>
gmu 2k6 wrote:
...
> so what does it mean that one of Xeons here shows me the full 4GiB as
> total physical memory via `free`?
>
> btw, the box I'm getting will have the 975X chip and include 4GiB RAM
> and if I understood the problem correctly even with 3GiB there will be
> some memory lost to mapping-issues besides the HI/LO mem
> kernel-reserving issue.
> this is what I get on ia32 P4 with 3GiB
> total used free shared buffers cached
> Mem: 3116108 2608196 507912 0 246652 2039708
> and this is what I get on ia32 Xeon with 4GiB
> total used free shared buffers cached
> Mem: 4087660 268828 3818832 0 57168 103568
Hi Gmu,
This is a bit divergent from the discussion, but will hopefully provide some
background.
The hardware my employer manufactures asks the BIOS to reserve several
largeish ranges (16M and 16M to 512M), and it's been used in various HPC
projects where machines typically have a lot of memory installed.
From my experience, most pre 750x-P4-Xeon chipsets did not support any kind
of memory remapping, so often the top 0.5-1.5G of ram would be 'lost'. Great
fun.
Since then, this functionality has started appearing, more or less randomly.
I believe it should be present on all later 75xx chipsets (probably the Core
2 Xeon chipsets as well), but implementation depends on the BIOS (ie the
motherboard vendors), and their grasp of what people do with their boards is
often quite limited.
On the P4 boards (and again the Core 2 boards as well), this is probably
even less ordered as they are 'desktop' boards rather than the more costly
'server' boards.
I'm pretty sure the Athlon64 and Opteron CPUs should support this, but they
too depend on BIOS functionality to rearrange the memory tables.
Just out of interest - what chipset does your Xeon system use?
Yours,
-S
--
Simen Thoresen, Dolphin ICS
next prev parent reply other threads:[~2006-08-10 21:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-08 8:24 Only 3.2G ram out of 4G seen in an i386 box Thomas Stewart
2006-08-08 10:15 ` Paul P Komkoff Jr
2006-08-08 19:51 ` David Schwartz
2006-08-09 6:51 ` gmu 2k6
2006-08-09 14:48 ` Joel Jaeggli
2006-08-09 14:54 ` gmu 2k6
2006-08-10 21:09 ` Simen Thoresen [this message]
2006-08-11 11:08 ` gmu 2k6
2006-08-13 10:54 ` Simen Thoresen
2006-08-10 13:04 ` Thomas Stewart
-- strict thread matches above, loose matches on Subject: below --
2006-08-08 9:13 Mikael Pettersson
2006-08-08 10:01 ` Thomas Stewart
[not found] <fa.FhtZk3YiH9OyGCt4iXIGt+vYtos@ifi.uio.no>
2006-08-08 14:22 ` Robert Hancock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44DBA06E.40104@dolphinics.no \
--to=simentt@dolphinics.no \
--cc=gmu2006@gmail.com \
--cc=joelja@uoregon.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox