2007-06-02 04:51:17

by Mike Richards

[permalink] [raw]
Subject: Missing RAM on x86_64

Hi, I appear to be missing quite a bit of RAM on an x86_64 system. I
have 1GB installed, but 'free' only shows 878MB:

pokey$ free -m
total used free shared buffers cached
Mem: 878 571 306 0 52 332
-/+ buffers/cache: 186 691
Swap: 1023 0 1023

I'm used to seeing a little bit of RAM missing with 32bit systems, but
146MB seems a bit much. The part of dmesg that concerns the RAM is
shown below. Anyone know what's up here? Is this normal for an x86_64
system?

Linux version 2.6.20.11 (root@pokey) (gcc version 4.1.2) #1 SMP Thu
May 24 18:29:52 GMT 2007
Command line: auto BOOT_IMAGE=2.6.20.11 rw root=801
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000037fd0000 (usable)
BIOS-e820: 0000000037fd0000 - 0000000037fde000 (ACPI data)
BIOS-e820: 0000000037fde000 - 0000000038000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 229328) 1 entries of 256 used
end_pfn_map = 1048576
DMI 2.3 present.
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 229328) 1 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
early_node_map[2] active PFN ranges
0: 0 -> 159
0: 256 -> 229328
On node 0 totalpages: 229231
DMA zone: 56 pages used for memmap
DMA zone: 890 pages reserved
DMA zone: 3053 pages, LIFO batch:0
DMA32 zone: 3079 pages used for memmap
DMA32 zone: 222153 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: nVidia MPTABLE: Product ID: MCP51G/M MPTABLE:
APIC at: 0xFEE00000
Processor #0 (Bootup-CPU)
I/O APIC #1 at 0xFEC00000.
Setting APIC routing to flat
Processors: 1
Nosave address range: 000000000009f000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000e0000
Nosave address range: 00000000000e0000 - 0000000000100000
Allocating PCI resources starting at 40000000 (gap: 38000000:c6c00000)
PERCPU: Allocating 25088 bytes of per cpu data
Built 1 zonelists. Total pages: 225206
Kernel command line: auto BOOT_IMAGE=2.6.20.11 rw root=801
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
CPU 0: aperture @ 61ba000000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 898964k/917312k available (2235k kernel code, 17744k reserved,
750k data, 200k init)


2007-06-02 08:51:30

by Eric Dumazet

[permalink] [raw]
Subject: Re: Missing RAM on x86_64

Mike Richards a ?crit :
> Hi, I appear to be missing quite a bit of RAM on an x86_64 system. I
> have 1GB installed, but 'free' only shows 878MB:
>
> pokey$ free -m
> total used free shared buffers cached
> Mem: 878 571 306 0 52 332
> -/+ buffers/cache: 186 691
> Swap: 1023 0 1023
>
> I'm used to seeing a little bit of RAM missing with 32bit systems, but
> 146MB seems a bit much. The part of dmesg that concerns the RAM is
> shown below. Anyone know what's up here? Is this normal for an x86_64
> system?
>
> Linux version 2.6.20.11 (root@pokey) (gcc version 4.1.2) #1 SMP Thu
> May 24 18:29:52 GMT 2007
> Command line: auto BOOT_IMAGE=2.6.20.11 rw root=801
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 0000000037fd0000 (usable)
> BIOS-e820: 0000000037fd0000 - 0000000037fde000 (ACPI data)
> BIOS-e820: 0000000037fde000 - 0000000038000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
> BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)


I would say your BIOS needs an update or some tweakings.

The (usable) parts that it gives to the OS (linux) are :

0000000000000000 - 000000000009fc00
0000000000100000 - 0000000037fd0000

Thats not 1024 MB, but 892 MB

Here is the output on a 16 GB x86_64 machine

BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
BIOS-e820: 000000007fff0000 - 000000007ffff000 (ACPI data)
BIOS-e820: 000000007ffff000 - 0000000080000000 (ACPI NVS)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000480000000 (usable)

On node 0 totalpages: 2097039
On node 1 totalpages: 2097152

total of 4194078 pages (while exact 16GB should be 4194304 pages)


2007-06-04 19:14:15

by Lennart Sorensen

[permalink] [raw]
Subject: Re: Missing RAM on x86_64

On Sat, Jun 02, 2007 at 12:51:07AM -0400, Mike Richards wrote:
> Hi, I appear to be missing quite a bit of RAM on an x86_64 system. I
> have 1GB installed, but 'free' only shows 878MB:
>
> pokey$ free -m
> total used free shared buffers cached
> Mem: 878 571 306 0 52 332
> -/+ buffers/cache: 186 691
> Swap: 1023 0 1023
>
> I'm used to seeing a little bit of RAM missing with 32bit systems, but
> 146MB seems a bit much. The part of dmesg that concerns the RAM is
> shown below. Anyone know what's up here? Is this normal for an x86_64
> system?

I you running a 64 or 32bit kernel? If it is 32bit then it is normal
for a kernel not configured with CONFIG_4GB or whatever it is called to
be limited to about 900MB ram. 64bit kernels should see all the ram no
matter what the config is. It looks very much like you are running a
32bit kernel though. What does uname -a say?

--
Len Sorensen