Comment 3 for bug 129172

A useful test/workaround is provided by mem=XXX. This allowed me to experiment. Here are the results.
In all cases, the system was booted in recovery mode (for speed of testing), appending mem=XXXM to the kernel command-line. All 4 DIMMs (8GB in total)
were always present.

Results:

boot param result of free-m (total) performance
-------------- ---------------------------- ----------------
mem=2048M 2015 normal
mem=6144M 5477 normal
mem=8192M 7497 normal
mem=8792M 8002 100x slow #measured by timing: for ((i=0;i<10000;i++)); do echo $i > /dev/null ;done
mem=10000M 100x slow
  [none] 100x slow

I then did a binary search to find the optimum. Where bootup was very slow, it was terminated with Alt-SysRQ-[RSEIUB] before completion, so "free -m" was not measured. (Unfortunately, it doesn't work to use "init=/bin/bash" to speed up the test cycle - why not?)

boot param free -m performance
-------------- --------- ----------------

mem=8500M slow
mem=8300M 7604 normal
mem=8400M slow
mem=8350M slow
mem=8325M slow
mem=8315M 7618 normal
mem=8320M slow
mem=8318M 7621 normal
mem=8319M slow

I also found these other links which might be relevant:
  http://www.hostingforum.ca/172078-slow-kernel-when-memory-8g.html
  http://lkml.org/lkml/2007/5/30/79

Lastly, looking at the difference between real, and reported memory: (always with 8GB of physical RAM), from above data

mem= free -m difference
-------- --------- ------------
2048 2015 33
6144 5477 667
8192 7497 695
8792 8002 790
8300 7604 696
8315 7618 697
              => No very clear pattern.

Anyway, the workaround, for now is to boot with "mem=8318M", which actually provides 7621MB of RAM (i.e. wasting 1171 MB).