Встает колом

1) Где ты увидел жалобу?

2) На предыдущем Debian таких жестких зависонов не было.

3) ВНЕЗАПНО, узкое место моей конфигурации - жесткий диск, а не процессор или память. С ними еще можно относительно комфортно работать, а вот долгая запись/чтение ЖД вызывает подтормаживание.

4) Зависания встречаются редко. Действительно, после тяжелых программ типа firefox/chromium. Да, я знаю про w3m и в основном им и пользуюсь.

На предыдущем Debian таких жестких зависонов не было.

А на десятилетней давности вообще все летало.

узкое место моей конфигурации - жесткий диск

Ну да, во всем виновен жесткий диск. Что же раньше он не был виноват? Как уже выше писали, сначала память, потом процессор и только потом жесткий диск. Я вот, например, не могу полноценно пользоваться нетбуком с 1гб памяти и с ионом вместо процессора, хотя туда воткнул бесхозный ssd. Сама ось работает, забирая всего 80мб, но зачем мне система только ради системы? Для «десктопа», а это прежде всего потребление контента и развлечения, есть более современные ноутбуки. Как «рабочая станция», то тут зависит от рабочих задач.

1-2 гиг озу в 2020 это натурально клиника. найми кого-то, кто разбирается в компьютерах, чтобы выбрал тебе нормальный на сегодняшний день по спекам

У меня лапки.

Раз в 3-5 лет меняют комп, а потом удивляются, а чего по всей планете такой пипец с экологией.

Что же раньше он не был виноват? Как уже выше писали, сначала память, потом процессор и только потом жесткий диск.

Это в случае указанного в теме бага. При обычной работе все относительно шустро работает, кроме операций записи/чтения.

Я вот, например, не могу полноценно пользоваться нетбуком с 1гб памяти и с ионом вместо процессора

Я пока еще могу. И ютубчик, и музыка, и даже игры (flare, старые под wine). Для Интернета - w3m, в крайнем случае, palemoon. Да, нетбук с 1 Гб и Intel Atom это вполне осилит (если дрова на видео не подведут в случае с играми).

P.S. Естественно, Youtube не в браузере. Я использую Yatube.

думаю нефтяным и прочим компаниям смешно с твоих оправданий

Нефть имеет свойство заканчиваться. А компании и так ничего не волнует кроме бабла.

Как я понял, 0 – ядро не запрещает оверкоммит, но есть эвристика, которая решает, когда запустить киллер. 1 – ядро вообще не следит за оверкомитом. 2 – оверкоммит запрещен (при overcommit_ratio <= 100). Правильно?

pf-kernel. Там тебе и uksm, и защита от трешинга.

pf-kernel

Но ведь в нем еще не исправлено падение сессии при использовании drm/i915 - https://github.com/hakavlad/le9-patch/issues/5

Встает колом

Порнуху не смотри

Примерно так, да.

Только при невозможности выделить память не киллер приходит, а обычно просто падение процесса с ошибкой Cannot allocate memory.

Никогда такого не видел и не испытывал.

А во фре такой же хаос с оверкоммитом и дикими программами алоцирующими гигабайты?

не знаю

1. У тебя интегрированная графика интел?
2. Ты проводил специальные стрессы?

У меня это было на деб9 и деб10, например. Легко воспроизводится - сессия падает после ООМ.

Я конешно извиняюсь, но если request приходит с __GFP_RETRY_MAYFAIL, то при чём тут я?

При том, что с твоими патчами падает, а без - не падает.

Спасибо всем, кто дал советы. Потенциальное решение оказалось до банальности простым. Оказывается, в fstab была неверная запись про swap раздел, и он вообще не использовался. Включил его, нагрузил систему, пока зависаний не наблюдаю. 2 Гб памяти + почти 3 Гб подкачки я вряд ли превышу. На всякий случай установил еще earlyoom, но необходимости в нем еще не возникало. На нетбуке с 1 Гб, где swap функционирует исправно, этой проблемы я вообще не замечал. Пока что помечаю проблему как решенную. По итогам отпишусь о результате.

1-2 гиг озу в 2020
anonymous (27.01.21 17:20:34)

Потому что нельзя просто так ставить рандомные патчи и слепо им доверять ☺. Понимание нужно́.

Кстати говоря, проблема решается добавлением одного return 0; в драйвер i915.

При 1 оверкомит разрешен, как и при 0.

При запуске uniq /dev/zero c 0 процесс упадет с cannot allocate memory, а с 1 будет убит киллером. В этом и разница.

То же самое с запуском stress -m 1 --vm-bytes 999G.

1 позволяет выделять терабайны памяти, 0 - не позволяет это делать просто так.

При 2 все понятно – оверкомит запрещен

Не запрещен, а зависит от overcommit ratio.

Этим летом отправлю, но инфа не 100%.

При нехватке памяти (предположительно) возникает очень высокий I/O, что ведет к общему зависанию.

Всё так. Для воспроизведения проблемы даже есть инструмент: https://github.com/hakavlad/file-starve