I am trying to understand the basics of the Linux OS. I'm running 64-bit Ubuntu 12.04 on a 64-bit CPU. The system has 2GB of RAM.

cat /proc/meminfo 
MemTotal:        2012040 kB

Question 1: Where is the missing 85112KB of RAM?

2097152 (2 gb in kilobytes)
2012040 -

Is this reserved for something else or is this a hardware limitation that the system cannot use 4% of the RAM?

Question 2: My initial reading tells me that there is a 3:1 split for user kernel space. Why is that not the case here?

(3/4)*2097152 =1572864 for user space
(1/4)*2097152 =524288  for kernel space

I am aware of Linux RAM caches and buffers (I spent some research effort to understand that at least), but this case it has nothing to do with that, so what's going on?


You really ought not to ask two questions in one, but...

Question 1

Some of that memory is used for the kernel code itself, some is reserved, etc. The kernel spits it out in the system boot messages:

[    0.000000] Memory: 6106920k/7340032k available (3633k kernel code, 1057736k absent, 175376k reserved, 3104k data, 616k init)

The "absent" line is memory that isn't actually there (this machine currently has 6GiB of RAM installed). The kernel also spits out the memory map (this is earlier in the boot messages):

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e2c00-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bf77ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000bf780000-0x00000000bf797fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000bf798000-0x00000000bf7d9fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000bf7da000-0x00000000bfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001bfffffff] usable

The kernel then does various fixups to that map, usually reserving more memory. Especially as the drivers load.

Question 2

The kernel/user split is of virtual address space, not memory. Its pretty much irrelevant on a 64-bit box, because there is so much address space to go around.

On a 32-bit box, virtual addresses 0x00000000–0xBFFFFFFF were used for user address space. 0xC0000000–0xFFFFFFFF were used by the kernel (that's the 3:1 split, other options inlcuded a 2:2 split. Note those numbers are gigabytes, so it's 2:2 not 1:1). Virtual addresses are process-specific, too (each process can have a page at 0x00001000, and it's a different page).

But a virtual address doesn't correspond to a byte of memory. It can be backed by basically four things:

  1. Nothing. The page isn't in use. Try to access it, get a segfault.
  2. Physical RAM. The MMU translates the virtual address to some physical address, which actually corresponds to capacitors on a DIMM somewhere.
  3. Swap (or memory-mapped file). If you access this, there will be a page fault, and the kernel will suspend your process while it reads the data into memory (and possibly writes other data to disk, to make room). Then the kernel updates the page tables, turning this into case #2.
  4. Zero page. This is a newly allocated page, which hasn't been used yet. When it is, the kernel will find a page of physical memory (possibly swapping other stuff out), fill it with zeros (for security), and then it's case #2.

Transparent huge pages makes more cases. There are probably a few less-important ones I've forgotten, too...

Anyway, my 64-bit chip has a 48-bit virtual address size. I'm not sure what split the kernel uses, but even if its half, that's 47 bits of space, well in excess of the 36-bit physical address size. And 131,072 GiB of RAM is too expensive... (And, remember, when it gets cheaper, there are a lot of bits left in 64, future processors will probably just allow more of them).

  • I never noticed a nnnk absent in the Memory line. Is that special to your hardware? – ott-- Jun 19 '13 at 16:40
  • @ott-- Mine is a pretty standard Intel i7 box. It probably only exists because I have >4GiB RAM (I'd guess its due to the PCI space) – derobert Jun 19 '13 at 20:49
  • @derobert Thanks for the explanation,can you please confirm this, out of 7340032k how can it become 6106920k. 7340032k-6106920k=1233112k. Even if we add (3633k kernel code, + 1057736k absent,+ 175376k reserved, + 3104k data, + 616k init) and subtract it from 7340032k There is still difference can you please confirm – learner Jul 8 '13 at 14:12
  • @learner total - absent - reserved = available. – derobert Jul 8 '13 at 15:27

Hardware reservations will take up a small amount of RAM, especially if you have an onboard graphics card that uses some RAM for its own operations. This happens with all operating systems.

  • I even tried in a virual environment,but still there is difference,i hope hardware limitation will not affect in case of virtual environment. – learner Jun 19 '13 at 15:38
  • @learner Software running in a virtual environment needs to communicate with the virtual hardware just like in the non-virtual case. There needs to be a zone in memory for the software and the hardware to exchange data. That memory has to come from somewhere — on-device RAM or motherboard RAM for a real device, VM memory for a virtual device. – Gilles 'SO- stop being evil' Jun 19 '13 at 23:35
  • The memory used by the onboard graphics card as "shared memory" is reported as "stolen memory" in dmesg | grep stolen. There are some other types of reserved memory as well, as derobert's answer explains. – tanius Aug 20 '16 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.