Consider the following:

$ dmesg  | grep 'Memory:'                                                                                                                                              
[    0.000000] Memory: 8009456K/8272776K available (8474K kernel code, 1293K rwdata, 3984K rodata, 1488K init, 1316K bss, 263320K reserved, 0K cma-reserved)

Effectively, this suggests that at boot system has 8009456K available for tasks (minus reserved stuff). However, after boot free and vmstat report something very peculiar

$ free -k ; vmstat -s | head -n 1                                                                                                                                      
              total        used        free      shared  buff/cache   available
Mem:        8059880     2774996     2667600      394196     2617284     4529964
Swap:       1048572         412     1048160
      8059880 K total memory

Strangely enough, a system that has already booted has more memory available, which seems logically the opposite of what one would expect - at boot time there should be less processes running therefore more total usable memory should be available. How can this be explained ?

  • May be it is caused by different methods of memory size calculation (such MiB or MB, KiB or KB)? – N0rbert Nov 25 '17 at 20:43
  • you don't have more available memory --- 8009456K of 8272776K available at boot. after boot 2774996K of 8059880K is used which equals 5284884K available. Or are you speakiing of total memory ? – ravery Nov 25 '17 at 20:52
  • 2
    @N0rbert no, if that was the case the number reported by free and vmstat would be smaller. 1 KB is0.97 KiB. – Sergiy Kolodyazhnyy Nov 25 '17 at 20:54
  • @ravery free and vmstat pull their information from /proc/meminfo , which says Total is physical RAM minus reserved stuff (by various hardware). The 2774996K you mention - that's total memory minus cache+buffers+free columns (according to the manual). In other words, I'm more interested in why kernel "sees" more physical ram after boot. Logically, at boot there'd be less hardware would reserve ram, but instead this appears as opposite. – Sergiy Kolodyazhnyy Nov 25 '17 at 21:10

During boot, and at a later stage than your extracted dmseg line, typically some memory is freed. Lets's work through an example from my computer:

First, we change the dmesg extraction command a little (edited):

$ dmesg  | grep -i 'Memory:'
[    0.000000] Memory: 15829128K/16472972K available (8480K kernel code, 1294K rwdata, 3984K rodata, 1492K init, 1316K bss, 643844K reserved, 0K cma-reserved)
[    0.009844] Freeing SMP alternatives memory: 32K
[    0.868465] Freeing initrd memory: 37044K
[    2.621648] Freeing unused kernel memory: 1492K
[    2.624095] Freeing unused kernel memory: 1748K
[    2.625334] Freeing unused kernel memory: 112K

Notice the freed memory above, after the summary line. Adding them all up I get that I should have 15869556 total. Now lets check, using your same command:

$ free -k ; vmstat -s | head -n 1
              total        used        free      shared  buff/cache   available
Mem:       15869556      113352    15461820        9792      294384    15454760
Swap:      16472060           0    16472060
     15869556 K total memory

Notice the expected total exactly equals the actual total.

  • Spot on. I've greped the lines Freeing from my dmesg, added them up - number comes out exactly to what free and vmstat reported. – Sergiy Kolodyazhnyy Nov 25 '17 at 22:28
  • 2
    It's worth mentioning that this is actually a lot more phenomenal than it appears. While the use of initram means that most of the resources needed to boot have already been loaded into memory by the time linux is loaded by the boot loader its still quite interesting that root's init, the shell and free don't end allocating any more memory. Thanks to the use of procfs looking up that information doesn't use any more memory than a kb at least either. – jdwolf Nov 25 '17 at 23:55
  • I liked the -i parameter handy for grepping on nvidia just now. – WinEunuuchs2Unix Nov 26 '17 at 1:53

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.