Linux malloc //малко e flame...

из 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к - кур.

Satan`s Defloration Incorporated

Останал съм с впечатление, че 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" ти дава необходимата детерминираност.

При мен на "echo 2 > /proc/sys/vm/overcommit_memory" с дефаулт 50%, примерът на l връща нулл даже и при по малки от 1к блокове (пробвах с 512 байта).

Всъщност на колкото и да е настроено /proc/sys/vm/overcommit_ratio, при "echo 2 > /proc/sys/vm/overcommit_memory" винаги трябва да връща нулл, разликата е само в размера на заделената памет.

хмм
ще го видя пак идните дни, може аз да съм объркал нещо

Satan`s Defloration Incorporated

И как ще пишеш Посикс програми, след като не знаеш кой и кога ти връща 0?

Аз лично предпочитам детерминираност пред икономия на памет. Паметта е евтина, като ми трябва повече, ще си купя.

Както споменах в предната дискусия, вече не проверявам дали malloc връща 0 -- да му мислят потребителите.

> Иначе поразрових архива на 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.

Ето това е пример за неправилно взето проектно решение. Вместо да се реши проблема там където трябва -- в грешните програми, се наказват програмистите на _правилно_ написаните програми.

Програмата проверява на колко е настроено комитването и ако е 2 изпълнява посикс клон, иначе според зависи - хватки колкото щеш, най простата е предупреждение на юзера за възможните последствия ако не си забрани оверкомитването - в най мързеливия случай. Ама тоз дето ти си избрал е връх на мързела.

Прав си, но донякъде - има проблеми с бързодействието които няма да се решат, освен това има алгоритми които искат огромно количество памет (имаш и ограничено адресно пространство) и този трик помага. Това ти е една възможност в повече - нищо не ти пречи да си администрираш с/мата да не я ползва, или като програмист да предупреждаваш юзера да я забрани.

А купуването не винаги върши работа, защото адресното ти пространство е ограничено.

Посикс програма? Ще проверява дали и какво има записано в някакъв специфичен за дадена версия на Линукс ядрото файл? И то ако е монтиран /proc?

Това не е преносима програма и никога не бих написал такава. Нали затова има Посикс стандарт -- като напишеш нещо да върви по един и същ начин на всички операционни системи, които го поддържат.

Проблемите с бързодействието винаги се решават най-добре там където са породени -- в случая в потребителската програма.