Think about memory pools for example...
Posted Mar 10, 2011 21:49 UTC (Thu) by epa (subscriber, #39769)
If you needed to have the total amount of real memory you malloc, most systems would need twice as much RAM.
If you have a huge swapfile but no overcommit, and if some applications allocate lots of memory and then unexpectedly start using all the memory they asked for, then your system will start swapping and running slowly. If you just overcommit memory, then when apps start using all the memory they allocated the system will become unstable and processes will be killed without warning by the OOM killer. It's clear which is preferable.
Posted Mar 11, 2011 0:37 UTC (Fri) by droundy (subscriber, #4559)
Surely you've run into the situation where you've been unable to log into a machine because it's swapping like crazy, and are thus unable to kill the offending process? Is that really preferable to being able to go in and fix things immediately? Of course, things are easier when you've got a desktop and are already logged in, but even then I've seen situations where just switching to a terminal took many, many minutes, not to suggest the possibility of opening a new terminal.
The large majority of OOM-killer experiences I've had have been situations where there was a memory leak involved. In such cases, the OOM killer is usually quite good at identifying the culprit and killing it. If you add enough swap, then the system freezes up indefinitely (or until you're able to get a killall typed into a terminal). Not a huge improvement in my book. In any case, it's not clear which is preferable.
Posted Mar 16, 2011 12:17 UTC (Wed) by epa (subscriber, #39769)
If the I/O scheduler were a bit smarter, then the swapping activities of processes would count against their I/O usage, so a single bloated Firefox process would not be able to monopolize the disk to the exclusion of everything else. Similarly there could be more fairness in physical RAM allocation, so it wouldn't be possible for one app to consume all the physical memory pushing everything else into swap; it would be limited to say 80%. (This is reasonable for desktop systems, of course for servers or number-crunching you don't care so much about interactive performance so you'd increase that figure.)
Posted Mar 16, 2011 17:43 UTC (Wed) by nix (subscriber, #2304)
Posted Mar 11, 2011 7:10 UTC (Fri) by rvfh (subscriber, #31018)
A quick look at top:
Mem: 3095608k total, 2405948k used, 689660k free, 292560k buffers
Swap: 722920k total, 43508k used, 679412k free, 1034276k cached
So there are 689 MB of unused memory! Not to mention 1 GB+ of of cached stuff for the system to grab in case of need.
Now let's see the memory usage (top two):
238m 126m 26m /usr/bin/systemsettings
294m 95m 23m /usr/lib/firefox-3.6.14/firefox-bin
So the two main memory users (systemsettings!?!) have committed more than half a gig of RAM, but use less than a quarter (I know these numbers are not perfect, but the idea remains).
And you want me to get rid of overcommit???
Posted Mar 16, 2011 12:19 UTC (Wed) by epa (subscriber, #39769)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds