lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 1 Oct 2007 09:27:20 -0700 (PDT)
From:	david@...g.hm
To:	Bernd Eckenfels <ecki@...a.inka.de>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Out of memory management in embedded systems

On Mon, 1 Oct 2007, Bernd Eckenfels wrote:

> In article <87odfj5krj.fsf@...p.tkv.asdf.org> you wrote:
>> Make kernel configuration option? (e.g. disable "over commit"
>> mis-feature :-)
>
> # egrep . /proc/sys/vm/overcommit_*
> /proc/sys/vm/overcommit_memory:0
> /proc/sys/vm/overcommit_ratio:50

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ