Less RAM Available than installed on Centos 7

Question

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?

Since this site is for servers, and a laptop is not (or at the very least should not be) a server, I'm voting to move this question to [unix.se]. The close vote you see is a move vote. — Jenny D, Jul 21 '16 at 10:00
@JennyD Don't you think the problem raised could be linked to servers too? — , Jul 21 '16 at 10:02
Hmm, useful but not really what I was aiming for (sorry, my mistake). Let's also see dmesg | grep -C 3 -i e820 please. — user, Jul 21 '16 at 10:41
Okay, I see some reserved ranges there, but nothing stands out to me like it would account for a missing 1.6 GB. Odd. (And if it were a GPU memory range reservation as suggested by Koen van der Rijt, I'd expect it to show up in the e820 data as a reservation.) — user, Jul 21 '16 at 10:54
does you laptop have an onboard GPU? it could be that its reserving RAM for that. check this similar post — Koen van der Rijt, Jul 21 '16 at 10:15
I have Intel Corporation 3rd Gen Core processor Graphics Controller (see the edit) but I don't know how to check how much RAM is it using and how to deallocate some RAM for the system to utilise. BIOS shows no option related to graphics card. — user994144, Jul 21 '16 at 10:30
@user994144 It might, but then again it might not, if it's caused by some specific hardware. In any case, here at [unix.se] are a lot of very knowledgeable Unix people. Getting a unix question moved here is not a demotion; it's a way to get the question to the place where you're more likely to find the best help with this particular question. — Jenny D, Jul 21 '16 at 18:04
Can you post output of these two commands: mount -t tmpfs -o size=80% none /tempRam; dd if=/dev/zero of=/tempRam/testFile bs=1M count=3096. It will allocate 80% of RAM size to tempRAM mountpoint and then will create the 3GB file into it. If free -m is not buggy then above command must throw an error saying No space left on device. — SHW, Aug 04 '16 at 06:49
Does it shows same available RAM if you boot from any other OS ? If you do not have another OS/distribution then can you check it from runlevel S or memtest86 ? — SHW, Aug 04 '16 at 08:00
Hard to see how this would be Linux-related if it doesn't work any better on Windows. Counting up the usable blocks from the BIOS RAM map comes up to that about 2.6 GB, and the reserved blocks to something like 1.6 GB, so it seems to come from the BIOS. Hard to know from here what it might be used for, though. — ilkkachu, Aug 06 '16 at 12:22
If it isn't related to GPU and reserved parts, the only thing comes to mind is if you are using any virtualization or not. It's really odd. So, what is this server/system for? What are you doing with it? Any virtualization?? If no, the problem should be related to your BIOS, and in that case, that's really hard to investigate problem from here. — , Aug 09 '16 at 17:26
from a similar post with Windows 7, the issue was with the BIOS memory remapping. You have more info here: https://support.lenovo.com/pl/en/documents/ht071267 — BitsOfNix, Aug 09 '16 at 20:57
Are you using COW feature? Copy-on-write, i.e. are you using snapshots? Shall I ask you about your partitioning? RAID, mappings, COW, ...??? Please tell us more about what you do with that system. — , Aug 10 '16 at 09:52

score 1 · Answer 1 · edited Jun 11 '20 at 14:16

1

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.

edited Jun 11 '20 at 14:16

Community

1

answered Aug 10 '16 at 10:25

BTW, I have emailed RedHat support for more information, I will update my answer whenever and if they add any more possible reasons, but personally I think there shouldn't be anything else. – Aug 10 '16 at 10:48
First: We are looking at Total memory and not just free memory. The total amount of memory claimed by the OS is way less than what is actually present.
Second: The BIOS is showing exactly the amount of RAM that is inserted into the machine.
– user994144 Aug 10 '16 at 12:27
@user994144 about the second, sorry my mistake, I removed the second part. About the first, I know, I see. As I mentioned, you can not get your total by adding up the memory being in use by other processes. – Aug 10 '16 at 12:32
There are many possible reasons, it differs from system to system. – Aug 10 '16 at 12:38
This is pretty much a clean install of Centos 7 with no virtualisation or such setup. I still don't see where the huge chunk of memory is being used as a similar setup on another machine yields expected availability of memory. – user994144 Aug 10 '16 at 12:38
So it might be really BIOS problem, not in showing, in serving. I have faced with ridiculous BIOS issues, I will again add the second reason to my answer since it really might be a reason even for your situation. – Aug 10 '16 at 12:41
Once again, BIOS shows 4096MB which is the exact amount of RAM that is inserted. – user994144 Aug 10 '16 at 12:43
1

Got you mate, I know it shows you the exact amount of RAM ;) Try to full 90-93 % of your RAM by doing the things explained here or whatever else, and test what will happen. – Aug 10 '16 at 12:44
Since we have no clue what the exact problem might be, you can only try to run some tests and monitor the changes. Monitoring is the best solution. – Aug 10 '16 at 12:49
We have tried similar approach. Please look at the last section of the question and comments. I tried filling 80% of it which failed. – user994144 Aug 10 '16 at 12:49
:o (!!!) Oh gosh! I haven't ever seen something like that. Lemme ask for help, and Imma keep you informed if any new thing could I find. Imma try my best to help you. – Aug 10 '16 at 12:52

score 0 · Answer 2 · answered Aug 10 '16 at 04:10

0

You might find this page to be immensely helpful.

TL;DR: The configuration for the laptop likely specifies less than is actually available. This can be changed in /boot/grub/grub.conf.

answered Aug 10 '16 at 04:10

theaustinseven

51

I have tried what is suggested in the article with no success. – user994144 Aug 10 '16 at 07:58
These docs are too old for the reported OS version. CentOS 7 uses grub2. – Mike Shultz Oct 13 '16 at 01:57

score 0 · Answer 3 · answered Aug 10 '16 at 04:49

You need to know how to recompile a kernel before to try to do something with it.

go to the linux kernel directory ( generally "/usr/src/linux" )
run make menuconfig ( or, make xconfig, gconfig etc... )
go to -> Processor types and features
go to -> High memory support
Then select the appropriate option to your machine ( the option "off" enable the support just do less than 4GB )
recompile the kernel make && make modules && make modules_install
don't forget to reconfigure your boot loader

I don't see the reason why current kernel doesn't show the correct memory size as I have installed the same OS on another computer using same method which works as expected. — user994144, Aug 10 '16 at 08:00

Arun Panneerselvam · Answer 4 · 2018-05-18T00:34:30.060

For GRUB, modify the GRUB config file located at /boot/grub/grub.conf, (and make sure the kernel version is correct)

# NOTICE: You have a /boot partition. This means that 
#  all kernel paths are relative to /boot/ 
default=0 
timeout=30 
splashimage=(hd0,0)/grub/splash.xpm.gz 
title Red Hat Enterprise Linux (2.6.9-5.EL)         
root (hd0,0)         
kernel /vmlinuz-2.6.9-5.EL ro root=/dev/hda3 mem=**128M**

and update the grub by,

sudo yum update-grub

Since CentOS 7 uses auto generated GRUB2, and /etc/default/grub file to make grub config using command grub2-mkconfig Use grub commandline to specify installed memory,

sudo nano /etc/default/grub

and add this line at the eof,

GRUB_CMDLINE_LINUX="mem=8192m"  (for 8GB)
sudo grub2-mkconfig

reboot the system for the changes to take effect. use, cat /proc/meminfo to view the complete memory usage of the system.

Less RAM Available than installed on Centos 7

4 Answers4

First

Second

The last