keep in mind that disabling overcommit will mean that you need to put more
ram in your embeded system to have it run
there can be very significant saving in ram from the fact that a large
program can do fork-exec of a small program without having to have enough
ram in the system for two copies of the large program.
you get even more savings in most systems from the fact that Linux does
copy-on-write when programs fork instead of allocating (and copying) all
the memory the program accesses. this allows programs that run multiple
copies to use the same memory for most of the requirements.
overcommit by default is optimistic that if the program requesting the
memory actually tries to use it there will be enough (both the fork-exec
situation and the copy-on-write memory of real forks mean that the system
ends up useing much less memory then is theoretically allocated).
switching it to be pessimistic (overcommit 2 IIRC) means that the OOM
handler will never kick in, but it means that programs will be told that
there isn't any memory when there really is enough for the program to
work.
if you think the pessimistic mode makes your embeded device deterministic
enough to avoid OOM go for it, but keep in mind that adding the same
amount of additional memory would also make the system safe with
overcommit (if everything works properly). it's only when you would rather
have the system fail an allocation immedialy rather then running any risk
of running into trouble later that you want to disable overcommit.
DavidLang
-
