Less available RAM after kernel upgrade

I run the amd64 version of Debian squeeze on a Linode 512. I noticed recently that the kernel I had been using, 2.6.35.4-x8664-linode16, wasn't the latest so I did a reboot to get 2.6.39-x8664-linode18.

After doing this, free -m reported that the total amount of memory (the value in the top left) was 435 mb. I knew it was always a little under 512 mb, but not that much. So I switched back to the old kernel and with the old kernel it says the total amount is 493 mb. This isn't a hugely important issue as I still have plenty of room for all my applications, but it's nice for as much as possible to be used for caching.

Is this expected behaviour, or is something not quite right?

7 Replies

I suspect that kernels tend to get larger as time goes on. Also, there have been a few memory allocation bugs in the recent kernels that tend to produce, uhh, somewhat odd numbers for available RAM:

Linux hansel 2.6.39-linode33 #5 SMP Sun May 29 02:01:17 UTC 2011 i686 GNU/Linux

root@hansel:~# dmesg | grep Memory
Memory: 480264k/4202496k available (5700k kernel code, 43576k reserved, 1666k data, 412k init, 0k highmem)

Nonetheless, if you take 512 MB (524288 KB) and subtract the amount it declares to be reserved (43576 KB in this case), you get pretty close to the reported available memory:

root@hansel:~# free
             total       used       free     shared    buffers     cached
Mem:        480676     234944     245732          0      20468     149096
-/+ buffers/cache:      65380     415296
Swap:       262140          0     262140

So, short answer is that the RAM is there, it's just taken by the kernel. One would also expect 64-bit kernels to take more RAM than an equivalent 32-bit kernel.

As a footnote, I have 464220 KB on a -linode33 #3 box and 480728 KB on a -linode33 #4 box, so 2.6.39 has been getting some jostling. (At least on the 32-bit side.)

@hoopycat:

I suspect that kernels tend to get larger as time goes on. (…)

As a footnote, I have 464220 KB on a -linode33 #3 box and 480728 KB on a -linode33 #4 box, so 2.6.39 has been getting some jostling. (At least on the 32-bit side.)
No kidding about the growth over time. I've typically stuck with the 2.6.18 series on most of my boxes (since I didn't need any missing features and I had some issues with original attempts with the paravirt kernels), but have been testing 2.6.39 #5 recently, and it's a big change:

$ uname -a
Linux portal 2.6.18.8-linode22 #1 SMP Tue Nov 10 16:12:12 UTC 2009 i686 GNU/Linux
$ grep Memory /var/log/dmesg
Memory: 511908k/532480k available (3989k kernel code, 12360k reserved, 1102k data, 224k init, 0k highmem)
$ free
             total       used       free     shared    buffers     cached
Mem:        524512     509280      15232          0      81604     276376
-/+ buffers/cache:     151300     373212
Swap:       262136        344     261792

$ uname -a
Linux utest 2.6.39-linode33 #5 SMP Sun May 29 02:01:17 UTC 2011 i686 GNU/Linux
$ grep Memory /var/log/dmesg
Memory: 480264k/4202496k available (5700k kernel code, 43576k reserved, 1666k data, 412k init, 0k highmem)
$free
             total       used       free     shared    buffers     cached
Mem:        480676     435976      44700          0     187436     168440
-/+ buffers/cache:      80100     400576
Swap:       262140          0     262140

Now, I know there's a difference in reporting by free (the total doesn't take off for kernel memory in 2.6.18), but 30MB more in reserved memory - the lion's share of the overall delta - represents a significant percentage of a Linode 512. Heck, that's equivalent to what my main application front-end takes up.

What I'm not sure is how much practical difference this represents. E.g., maybe 2.6.39 just locks down more memory but is still using it for similar things as 2.6.18, so it may not represent as much practical loss to the system as it might appear, especially since it's not like you expect to involve swapping much on a VPS anyway.

– David

Hmm, just checked mine after I rebooted into the latest paravirt kernel, running x64 CentOS on a 768 MB:

# free -m
             total       used       free     shared    buffers     cached
Mem:           676        628         47          0         35        422
-/+ buffers/cache:        170        506
Swap:          127          0        127

:?

Just to add to the confusion… :o

mnordhoff@cheezum:~$ uname -a
Linux cheezum 2.6.32.16-linode28 #1 SMP Sun Jul 25 21:32:42 UTC 2010 i686 GNU/Linux
mnordhoff@cheezum:~$ free -m
             total       used       free     shared    buffers     cached
Mem:           751        436        314          0         41        205
-/+ buffers/cache:        189        562
Swap:          255         34        221
mnordhoff@cheezum:~$ dmesg | grep Memory
Memory: 768980k/786432k available (5104k kernel code, 16796k reserved, 1584k data, 396k init, 47112k highmem)

Just for statistic:

Mem: 435296k total

2.6.39-x86_64-linode18

This has improved in 2.6.39.1 for 32 bits:

Linux ur-mom 2.6.39.1-linode34 #1 SMP Tue Jun 21 10:29:24 EDT 2011 i686 GNU/Linux
Memory: 509012k/532480k available (5701k kernel code, 23020k reserved, 1656k data, 412k init, 0k highmem)

If you're running 64 bit you're still boned.

-Chris

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct