First, if your BIOS/UEFI does not detect correctly your RAM, then your OS won't do any better. There's no need to go any further if your BIOS display incorrect information about your setup.
=> You probably have at least an hardware problem.
EDIT: From your dmesg | grep memory, it seems that you have in fact an hardware problem, located in your embedded bios. At least, Linux has detected it and warns you about it : WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM
. It also seems that one of your 4 ram module is incorrectly recognised or inserted.
You can either report it to your manufacturer, upgrade your bios and change your motherboard. There's many chance that with less RAM, you won't encounter this bug.
As a side note, you may agree with this famous quote from Linus Torvalds about BIOS makers :
BIOS writers are invariably totally incompetent crack-addicted monkeys
Second, when your BIOS is OK with what you really have on your motherboard, you can take a look on Linux at /proc/meminfo
. It's often very clear about what your linux system know and do with your memory. Here is what I have on my 64bit / 8 Gb of RAM :
$ cat /proc/meminfo
MemTotal: 8175652 kB
MemFree: 5476336 kB
Buffers: 63924 kB
Cached: 1943460 kB
SwapCached: 0 kB
[...]
About the boot process and what is used/freed by linux kernel, you can grep it from dmesg
:
$ dmesg | grep Memory
[ 0.000000] Memory: 8157672k/8904704k available (6138k kernel code, 534168k absent, 212864k reserved, 6896k data, 988k init)
EDIT : As Gilles said, with dmidecode --type memory
, you can have details about your hardware configuration. It looks like this for a 4x2Gb system :
$ sudo dmidecode --type memory
# dmidecode 2.9
SMBIOS 2.6 present.
Handle 0x0020, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x0022, DMI type 17, 28 bytes
Memory Device
Array Handle: 0x0020
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
[...]
[This block is repeated for each module]
There's an EXE installer for Puppy Linux which boots from an .iso on FAT32, NTFS or Linux filesystems (i.e. ext2/ext3/ext4, xfs, etc.) using syslinux and runs in RAM using unionfs/aufs with full access to persistent storage (disk, SD, flashdrive, etc.).
Other ISOs can be mounted, from commandline or script of course, as well as by clicking on them in the included ROX-Filer file manager. One convenient use of this is to selectively access or restore files from an old version instead of having to roll back everything.
The original Puppy Linux distribution ISO, which itself is an usually an ext3/4 filesystem, is kept on the lowest layer of the aufs stack. Changes are recorded in the topmost layer and flushed to disk periodically (configurable) to a "savefile". On boot, the original ISO is loaded to RAM and mounted read-only, then the savefile is loaded and mounted read-only to overlay it and an empty read-write layer mounted for any new changes. To preserve a history of changes, just setup automatic or manual coping of the savefile ISO to an archival directory.
The O/S "layering" of unionfs/aufs along with multi-mounting of filesystems are the core technologies at work here, so if Puppy Linux doesn't work for you, look for other distros using them.
There are quite a number of installation options available for Puppy Linux including a Windows EXE Installer which is a separate package that sets up the Windows boot loader for dual-boot.
Best Answer
I believe you would want to use something like
cgroups
to limit resource usage for a individual process.So you might want to do something like this except with
cgcreate -g memory,cpu:chromegroup cgset -r memory.limit_in_bytes=2048 chromegroup
to create chromegroup and restrict the memory usage for the group to 2048 bytes
cgclassify -g memory,cpu:chromegroup $(pidof chrome)
to move the current chrome processes into the group and restrict their memory usage to the set limit
or just launch chrome within the group like
cgexec -g memory,cpu:chromegroup chrome
However, it's pretty insane that chrome is using that much memory in the first place. Try purging reinstalling / recompiling first to see if that doesn't fix the issue, because it really should not be using that much memory to begin with, and this solution is only a band-aid over the real problem.