Andrew Lentvorski wrote:
Mike Marion wrote:
Don't get me started on their incredibly stupid ass code that can be
broken by future kernel changes to values in /proc/meminfo, doing
things like causing variable overflow that makes a program malloc()
anywhere from 400meg to 980gig! at startup. This was due to a feature
they deliberately did to attempt to malloc all the ram the app thought
it might need at startup... because "it's faster that way."
As much as I hate EDA companies, I'm going to defend them on this even
though they got the explanation (sorta) wrong.
The issue is not that it is faster for the application.
The issue is that the Linux kernel *lies*.
If you ask the Linux kernel for memory, it immediately returns "Here ya
go, boss." *but doesn't allocate the [EMAIL PROTECTED] memory* until you touch it.
Because, well, that's faster.
So, you allocate a nice set of pages you think is plenty big enough to
hold your very long, very complicated computation that's going to use
all that memory and halfway through *BOOM*--out of memory. So, your
choices are to touch *every single byte* up front in order to make Linux
actually give you the blasted memory (stupid when I'm actually going to
touch the memory when I use it anyhow), or bash some undocumented things
to make sure that the kernel can and will give you the memory when you
get there.
This kind of stuff is the reason I avoid Linux when I want reliability.
Yeah, it only bites you at the edges, but there are *lots* of edges.
And the Linux community takes its cue from Linus and ignores things that
are 1% fails if they get in the way of "performance" (see async writes
to disk as default for another example).
You seem to be unaware that you can turn the overcommit behavior off.
The memory allocation behavior is controlled through the
/proc/sys/vm/overcommit_* control, where * is either memory or ratio.
For the memory overcommit, from
<http://www.linuxinsight.com/proc_sys_vm_overcommit_memory.html>
overcommit_memory
Submitted by admin on Wed, 2006-05-31 16:52.
Controls overcommit of system memory, possibly allowing processes to
allocate (but not use) more memory than is actually available.
* 0 - Heuristic overcommit handling. Obvious overcommits of address
space are refused. Used for a typical system. It ensures a seriously
wild allocation fails while allowing overcommit to reduce swap usage.
root is allowed to allocate slighly more memory in this mode. This is
the default.
* 1 - Always overcommit. Appropriate for some scientific applications.
* 2 - Don't overcommit. The total address space commit for the
system is not permitted to exceed swap plus a configurable percentage
(default is 50) of physical RAM. Depending on the percentage you use, in
most situations this means a process will not be killed while attempting
to use already-allocated memory but will receive errors on memory
allocation as appropriate.
So to turn off the overcommit behavior you would do:
# echo "2" > /proc/sys/vm/overcommit_memory
Also for the overcommit ratio
<http://www.linuxinsight.com/proc_sys_vm_overcommit_ratio.html>
overcommit_ratio
Submitted by admin on Wed, 2006-05-31 16:55.
Percentage of physical memory size to include in overcommit calculations.
Memory allocation limit = swapspace + physmem * (overcommit_ratio / 100)
swapspace = total size of all swap areas
physmem = size of physical memory in system
Gus
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
