Потенциально менее надежно. Ядро себя при управлении ресурсами точно не обидит. И поэтому чтобы скопытился именно важный компонент ядра - ну разве что после всего остального уже, если душняк почему-то не пропал (e.g. conntrack неадекватный размеру RAM на мелкой мыльнице).

А вот для юзермода удостовериться что никогда не поплохеет софтине рулящей такими аспектами - очень нетривиально. Отдельные приветы всякой пихтонрасии, где это вообще mission impossible.

> Пусть живёт там себе дальше.

Однако почему б что-то такое не было в кернеле - все ж вопрос. А юзермод мог бы конфигурять. Ну вон OOM killer так примерно и работает, но он врубается либо если памяти совсем нет, либо если его мануально по alt-sysrq-f позвать.

Возьмётесь?

// b.

ЧЯДНТ?

бэкап. А у товарища - с fs на нее же или другую такую же, и обе, небось, ext4 с _журналом_ (это важно). То есть очень похоже на 12309 во всей его красе. И важно не число гигов (главное чтоб на порядок больше чем кэш позволяет вместить) а количество, фоточки плохой тест, вот как у анона - исходники UE - хороший.

Там, правда, насмерть не висло, но прервать этот процесс при околонулевой реакции системы было непросто.

А учитывая что его с тех пор десять раз починили и даже два раза закрыли - теперь при каких-нибудь интересных сочетаниях условий может и виснуть ;-)

И?
2 окна браузера по 3 вкладки c  Opennet и LOR.
Виртуальный ящик с древней XP и не менее древней версией (пустого) фотошопа 7 (причем, емнип, виртуалка отжирает у системы только действительно задействованную память).
И собственно все – 2.32 из 4 ГБ как корова языком.

А если в виртуалке нужно будет запустить фотожоп свежее 18 лет (да еще и не просто для запуска вхолостую, а для обработки чего-то) и вместо лора в браузере открыть тройку вкладок "жирной" доки страниц на тыщу?

Ну, правильно, кто ж сейчас маны то читает и вес процессам для oom killer настраивает? :)

i3-2100 CPU @ 3.10GHz, 8 ГБ памяти, диск ST500DM002-1BD14

# cat /proc/meminfo | fgrep Swap
SwapCached:         9176 kB
SwapTotal:       8273916 kB
SwapFree:        7804412 kB

> А также в чем пишешь код

vim

>  и запускаешь?

Эээ, mate terminal через команду ./a.out

> Интересно до жути.

Фирму мышки и клавиатуры не сказать?

Вы, наверное, имеете в виду ядро Linux, а не ОС...

> до сих пор не имеет средств для разруливания такой ситуации?

Вы меня спрашиваете? Я - пользователь ОС. Я получил плохо-отзывчивую систему в определённой ситуации.

Вот пример, который уводит мою систему во фриз:
'''
#include <stdint.h>
#include <stdlib.h>

int main()
{
while (1) {
uint64_t *buf = malloc(1024 * 1024 * 1024);

if (buf != NULL) {
for (int i = 0; i < 1024 * 1024 * 1024 / 8; i += 4096 / 8) {
buf[i] = 0;
}
}
}
return 0;
}
'''

RSX11, последние версии - 1982го года. Там примерно так и было принято.

Только вот это была - RT OS, и память там выделяли чтоб получить предсказуемое время реакции, а не потому что по другому не умела.

Но потом это всех затрахало, и кто мог - спер unix6, а кто не мог - вынужден был переизобретать его.

Не. Там всё будет жёстко тормозить, но хоть как-то реагировать. То есть если не психованный, то можешь вывести компьютер из этого положения без удара ногой по кнопке ресет на корпусе.
С линуксами бесполезно.

> Так и скажи что ты просто не умеешь линем пользоваться

Возможно и можно как-то настроить, и так далее... Но не имею желания - проще ОЗУ закидать.

Поправил, не благодари.

Да как-то среди Windows и MacOS не особо. Особенно первые так и вообще только так матом покрою разработчиков, если у них на васян репаке что не заработает 😀

Показать как Linux работает без fstab? :) Systemd смешно чертыхается, конечно, но ничего фатального не происходит.

что бы не выжирал память за считанные секунды.
>Вы не увидели там while (1)?

Действительно он есть, что еще более странно что будет когда malloc будет возвращать ошибку
while(1){} одно ядро убили.

я похожие тесты крутил очень очень давно, когда памяти было действительно мало. И они закачивались тем что процесс умирал после жуткого просиживания по io. То что у вас  gui  просто встает колом тоже нормально это регулируется приоритетами процессов по io.

а вот посадить такую  membomb в cgroups я не пробовал, думаю сейчас это решило бы практически все проблемы

Учтите что соотношение размера оперативной памяти и размер свопа очень сильно влияет на ваши тормоза. Добавьте sleep где-то 1-5 секунд запустите vmstat/iotop или что то подобное и вам сразу станет понятно откуда тормоза.
вот вам маленькая шпаргалка https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-

в ядре все нормально на самом деле, дополнительное накручивание автоматики только вред приносит.