Less available RAM after kernel upgrade
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
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
# free -m
total used free shared buffers cached
Mem: 676 628 47 0 35 422
-/+ buffers/cache: 170 506
Swap: 127 0 127
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)
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