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 kBQuestion 1: Where is the missing 85112KB of RAM?2097152 (2 gb in kilobytes)2012040 -______________ 85112Is 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 spaceI 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?
What happened to my RAM?
linux;memory
You really ought not to ask two questions in one, but...Question 1Some 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] usableThe kernel then does various fixups to that map, usually reserving more memory. Especially as the drivers load.Question 2The 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 0x000000000xBFFFFFFF were used for user address space. 0xC00000000xFFFFFFFF 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:Nothing. The page isn't in use. Try to access it, get a segfault.Physical RAM. The MMU translates the virtual address to some physical address, which actually corresponds to capacitors on a DIMM somewhere.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.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).