из man 3 malloc
> Linux follows an optimistic memory allocation strategy.
> This means that when malloc() returns non-NULL there is no
> guarantee that the memory really is available. In case it
> turns out that the system is out of memory, one or more
> processes will be killed by the infamous OOM killer.

някой може ли да ми обясни (ОБЕКТИВНО моля) какъв е смисъла на тая работа? значи човек чинно си проверява пойнтера дали е НУЛЛ, ама нещо не е така. значи трябва при всяка алокация да проверявам колко е работната памет + суап и дали случайно не искам повече??

проблема е ясен, ама не сматаш ли че е леко голяма глупост? има си дефиниран в стандарта механизъм, указателя е нула и errno e ENOMEM. защо да не се следва? от там нататък програмата да се оправя, защо, какво и как.

Представи си, че имаш 2 процеса които са резервирали сумарно памет по голяма от физически наличната, но единия (примерно вторият) не я е използвал. Може така да се случи, че първия процес да освободи паметта преди втория да я е използвал - тогава ще се мине без убийства - и вълка сит и агнето цяло. Ще питаш защо не я задели в момента когато ще я използва - защото може да е много нерационално да заделя байт по байт всеки път когато му трябва един байт повече памет.

Това си е чисто оправдание. Факт е, че Линукс (а и доста други Юникс операционни системи) не спазва POSIX спецификациите.

Ами аз не съм изпадал в такава ситуация, но доколкото прочетох, без OOM най-често се получава мъртва система. Явно са сметнали, че луд е за предпочитане пред мъртъв. :)

Използването на друга стратегия вместо memory overcommit не противоречи на използването на OOM killer.

дори и да се зададе на кърнъла да не дава повече рам от определен %, примерно 50% (с толкова пробвах), процеса пак бива убит, когато се опита да ги превиши, макар че "системата" си има достатъчно памет! и това убиване става, когато се malloc()ват малки блокове. Щото примерчето с по 10МБ наведнъж си връща NULL по някое време, но като се замени с 1к - кур.

Съдържаниет е скрито
Влезте за да го видите

Останал съм с впечатление, че OOM killer влиза в действие, когато се използва memory overcommit и паметта е на изчерпване.
Иначе поразрових архива на lkml и май една от причините за използване на memory overcommit е
a lot of those large (FORTRAN) simulations allocate huge arrays, then use only a small amount of it, depending on the specifics of the problem that run. Yes, they could be recoded to use sparse-matrix techniques, but that takes time and resources that could be better used. And may actually run slower.
Сигурно има и други причини да се наложи като стратегия по подразбиране, но не ми се търси повече. Ако при изключен overcommit има бъгове - има и bugzilla :).

Оправдание което оправдава. Оказва се, че в повечето случаи този начин на управление на паметта е по рационален (когато няма голямо значение за процеса дали ще бъде убит или ще излезе културно) от гледна точка на икономия на памет. А когато е необходимо, "echo 2 > /proc/sys/vm/overcommit_memory" ти дава необходимата детерминираност.