linux-kernel - Re: Out of memory management in embedded systems

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]

Message-ID: <Pine.LNX.4.64.0710010916570.20712@asgard.lang.hm>
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/