Linux – Less RAM Available than installed on Centos 7

linuxmemory

I can't seem to figure out why do I have less RAM usable than installed. I am running 64bit Centos 7 with 1 RAM module of 4096MB on a Lenovo x230. Some information from the machine in question:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           2439        1129         172         124        1137         857
Swap:          2087          41        2046


$ cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

$ uname -m
x86_64

$ dmidecode -t memory | grep -i size
    Size: 4096 MB
    Size: No Module Installed

$ lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Stepping:              9
CPU MHz:               1639.519
BogoMIPS:              5786.51
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              4096K
NUMA node0 CPU(s):     0-3

BIOS shows 4096MB RAM to be installed.

$ dmesg | grep -C 3 -i mtrr
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0x11e600 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0FFC00000 mask FFFC00000 write-protect
[    0.000000]   1 base 000000000 mask F80000000 write-back
[    0.000000]   2 base 080000000 mask FC0000000 write-back


$ dmesg | grep -C 3 -i e820
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.0-327.13.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Mar 31 16:04:38 UTC 2016
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-327.13.1.el7.x86_64 root=/dev/mapper/centos00-root ro crashkernel=auto rd.lvm.lv=centos00/root rd.lvm.lv=centos00/swap rhgb quiet LANG=en_ZA.UTF-8
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000040005000-0x000000008c0a0fff] usable
[    0.000000] BIOS-e820: [mem 0x000000008c0a1000-0x00000000dae9efff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000dae9f000-0x00000000daf9efff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000daf9f000-0x00000000daffefff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000dafff000-0x00000000df9fffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed08000-0x00000000fed08fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffc00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000011e5fffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] DMI: LENOVO 2325SRQ/2325SRQ, BIOS G2ETA5WW (2.65 ) 09/17/2015
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0x11e600 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
--
[    0.000000]   8 base 11E800000 mask FFF800000 uncachable
[    0.000000]   9 base 11E600000 mask FFFE00000 uncachable
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] e820: last_pfn = 0x8c0a1 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000f0100-0x000f010f] mapped at [ffff8800000f0100]
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
--
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xffbfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xffc00000-0xffffffff]
[    0.000000] e820: [mem 0xdfa00000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:5120 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 31 pages/cpu @ffff88011e200000 s87168 r8192 d31616 u262144
--
[    0.078755] ACPI: bus type PCI registered
[    0.078756] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.078931] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.078933] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
[    0.079010] PCI: Using configuration type 1 for base access
[    0.079718] ACPI: Added _OSI(Module Device)
[    0.079720] ACPI: Added _OSI(Processor Device)
--
[    0.116705] usbcore: registered new device driver usb
[    0.116763] PCI: Using ACPI for IRQ routing
[    0.118451] PCI: pci_cache_line_size set to 64 bytes
[    0.118883] e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff]
[    0.118884] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff]
[    0.118885] e820: reserve RAM buffer [mem 0x8c0a1000-0x8fffffff]
[    0.118886] e820: reserve RAM buffer [mem 0x11e600000-0x11fffffff]
[    0.118961] NetLabel: Initializing
[    0.118962] NetLabel:  domain hash size = 128
[    0.118963] NetLabel:  protocols = UNLABELED CIPSOv4


$ lspci -vnn | grep VGA -A 12
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
    Subsystem: Lenovo Device [17aa:21fa]
    Flags: bus master, fast devsel, latency 0, IRQ 27
    Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
    Memory at e0000000 (64-bit, prefetchable) [size=256M]
    I/O ports at 6000 [size=64]
    Expansion ROM at <unassigned> [disabled]
    Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
    Capabilities: [d0] Power Management version 2
    Capabilities: [a4] PCI Advanced Features
    Kernel driver in use: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])

Checking if free -m is not buggy:

mount -t tmpfs -o size=80% none /tempRam
dd if=/dev/zero of=/tempRam/testFile bs=1M count=3096

output:

dd: error writing ‘/tempRam/testFile’: No space left on device
1952+0 records in
1951+0 records out
2046541824 bytes (2.0 GB) copied, 4.74288 s, 431 MB/s

Any idea why do I have only 2.4gb RAM available and how to be able to use all 4GB?

Best Answer

There are many possible reasons, and it's a bit impossible/infeasible to investigate the issue from here without completely monitoring the system.

But here I'm going to list three possible reasons:

First

The reason may differ due to tasks you have on your system and things you are doing, it can differ if you use any virtualization, if any associated processes with doing snapshots and through COW memory allocation (Copy-on-right), partitioning rules you are running, memory-mapped file I/O, shared objects being intended to be shared by executable files and further shared object files, dynamic linking (late binding) and etc.

In addition, be aware that you cannot always find your real total memory by adding up the memory being in use by all running processes. There are many applications appear to be using more memory than actually exists on the machine, due to shared object and other RAM related concepts.

In addition, free memory is all about physical memory that has no logical data mapped to it. Yes, we should be aware that unused memory part has some data mapped to it but not in active state and use by a running process.

BTW, Notice that Unix-like systems wanna have - and show - as little free memory as possible, not all free memory! So from what you might have guessed, they use memory which is not actively mapped to processes in the running machine for things like buffers for various IO transfer operations and caches.

Second

Your BIOS might be buggy, BUT since it's showing the exact amount of RAM, we can say there is nothing wrong with BIOS, and the thing is that the kernel is not using it.

The last

The last thing I'm going to list, is somehow the first thing comes to anybody's mind, and that is reserved RAM for GPU related stuff, specially if you have an on-board GPU. But since the output of your dmesg | grep -C 3 -i e820 shows nothing wrong, so, this is not your problem.

It is real hard to say what your problem is since we have no deep understanding on your server but all you've mentioned in your question and comments, and I think we can do nothing more from here.

I recommend you ⟼ Do some test, for instance download memtest86+ by running yum install memtest86+ and try to test your memory and see what your exit code is. And monitor your system memory for a while, by using commands such vmstat -a, vmstat -s, cat /proc/meminfo, top, htop, sar -r etc., and see if you see anything weird.

If the above recommendation didn't help ↴

Two other final options: First, re-seat your ram, this Lenovo support may help you on it. Second, rebuild and install a new kernel.

I hope this could be help.

Related Solutions

Linux – 64-bit Linux doesn’t recognize the RAM between 3 and 32 GB

First, if your BIOS/UEFI does not detect correctly your RAM, then your OS won't do any better. There's no need to go any further if your BIOS display incorrect information about your setup.

=> You probably have at least an hardware problem.

EDIT: From your dmesg | grep memory, it seems that you have in fact an hardware problem, located in your embedded bios. At least, Linux has detected it and warns you about it : WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM. It also seems that one of your 4 ram module is incorrectly recognised or inserted.

You can either report it to your manufacturer, upgrade your bios and change your motherboard. There's many chance that with less RAM, you won't encounter this bug.

As a side note, you may agree with this famous quote from Linus Torvalds about BIOS makers :

BIOS writers are invariably totally incompetent crack-addicted monkeys

Second, when your BIOS is OK with what you really have on your motherboard, you can take a look on Linux at /proc/meminfo. It's often very clear about what your linux system know and do with your memory. Here is what I have on my 64bit / 8 Gb of RAM :

$ cat /proc/meminfo 
MemTotal:        8175652 kB
MemFree:         5476336 kB
Buffers:           63924 kB
Cached:          1943460 kB
SwapCached:            0 kB
[...]

About the boot process and what is used/freed by linux kernel, you can grep it from dmesg :

$ dmesg | grep Memory
[    0.000000] Memory: 8157672k/8904704k available (6138k kernel code, 534168k absent, 212864k reserved, 6896k data, 988k init)

EDIT : As Gilles said, with dmidecode --type memory, you can have details about your hardware configuration. It looks like this for a 4x2Gb system :

$ sudo dmidecode --type memory
# dmidecode 2.9
SMBIOS 2.6 present.

Handle 0x0020, DMI type 16, 15 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 32 GB
    Error Information Handle: Not Provided
    Number Of Devices: 4

Handle 0x0022, DMI type 17, 28 bytes
Memory Device
    Array Handle: 0x0020
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 2048 MB
    [...]
[This block is repeated for each module]

Centos – why centos7 free command output available value less than free value

Buffered/cached is RAM that was used by a process - say, Firefox - but the process has ended. But the system doesn't actually need that ram right now, so why flush it out? Someone may want to read that Firefox binary and associated libs back into memory... so it is kept cached in RAM until that RAM is needed by a process OR the Firefox (or whatever) binary is re-launched.

You can test this by rebooting your system, and then after your desktop has fully loaded, etc. start Firefox or Chrome or the Gimp or some other larger app, and time how long it takes. Once it is open, close it. Wait a moment or three, maybe check via ps or other utils that it is really no longer running. Then start the timer and launch it again. Much faster, yes? That is because instead of re-reading the binaries/libs back into RAM it simply re-marks the cached RAM areas as "in use".