On amd64, when selecting CONFIG_NO_BOOTMEM=y there is too much early reserved memory by the kernel. On a 12GB i7 system, these leaves only 3GB free once the system is up.
Created attachment 238729 [details] Diff between early dmesg on system with CONFIG_NO_BOOTMEM=n versus CONFIG_NO_BOOTMEM=y
On an affected system: blueness@localhost ~ $ sudo zcat /proc/config.gz | grep BOOTMEM CONFIG_NO_BOOTMEM=y blueness@localhost ~ $ free -m total used free shared buffers cached Mem: 2989 631 2358 0 27 234 -/+ buffers/cache: 369 2620 Swap: 2055 0 2055
On the same system blueness@localhost ~ $ uname -a Linux localhost 2.6.34-hardened #1 SMP Wed Jul 14 12:14:26 EDT 2010 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux blueness@localhost ~ $ sudo zcat /proc/config.gz | grep BOOTMEM # CONFIG_NO_BOOTMEM is not set blueness@localhost ~ $ free -m total used free shared buffers cached Mem: 12035 11960 75 0 11194 160 -/+ buffers/cache: 606 11429 Swap: 2055 0 2055
I just tested and this problem also affects x86. On a xen vm with 6GB of ram, the system kernel panics when CONFIG_NO_BOOTMEM=y. The panic reports "122 pages non-shared. Out of memory and no killable processes ..."
Created attachment 238761 [details] amd64 .config file where # CONFIG_NO_BOOTMEM is not set
Created attachment 238763 [details] x86 .config with CONFIG_NO_BOOTMEM=y
Hi, I have the same bug, but it seems to be fixed with the last grsec patch (grsecurity-2.2.0-2.6.34.1-201007162107.patch at this time) I now get my 8GB ram again
(In reply to comment #7) > Hi, > > I have the same bug, but it seems to be fixed with the last grsec patch > (grsecurity-2.2.0-2.6.34.1-201007162107.patch at this time) > I now get my 8GB ram again > Yes, I can confirm this. The fix will be included in the next rev bump of hardened-sources.
Fix is in the tree with hardened-sources-2.6.34-r1.