https://www.opennet.ru/openforum/vsluhforumID3/118253.html Бастьен Ночера (Bastien Nocera) анонсировал (http://www.hadess.net/2019/08/low-memory-monitor-new-project.html) новый обработчик нехватки памяти для рабочего стола GNOME - low-memory-monitor (https://gitlab.freedesktop.org/hadess/low-memory-monitor/). Демон оценивает нехватку памяти через /proc/pressure/memory и при превышении порога отправляет через DBus предложение процессам о необходимости умерить аппетиты. Также демон может пытаться сохранить отзывчивость системы через запись в /proc/sysrq-trigger. <br><br><br>В комбинации с проведённой в Fedora работой по применению zswap и прекращению использования дисковой подкачки, low-memory-monitor позволяет добиться повышения отзывчивости и качества работы на большинстве рабочих станций. Проект написан на языке C и поставляется (https://gitlab.freedesktop.org/hadess/low-memory-monitor/) под лицензией GPLv3. Для работы демона необходимо ядро Linux 5.2 или новее. <br><br><br>URL: https://www.reddit.com/r/linux/comments/ctyzhc/lowmemorymonitor_new_project_announcement/<br><br>Новость: https://www.opennet.ru/openforum/vsluhforumID3/118253.html#100 Tue, 27 Aug 2019 03:33:41 GMT &gt; Надеюсь еще и вручную оптимизированная под конкретный размер кэшей конкретной линейки CPU <br>&gt; конкретного производителя, с ассемблерными вставками, профайлингом доведенными до совершенства <br>&gt; скорости работы на конкретном поколении конкретной линейки CPU конкретного производителя. <br><br>Ведь я указал, какой конкретно файл можно посмотреть, без лишних поисков. Но, похоже, сделал недостаточный для знатока ассоциативности кешей акцент на разрядности. Так вот, преимущества 64-х битной арифметики не используются. То есть не очень-то упомянутая функция на С и "кроссплатформенная".<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#99 Tue, 27 Aug 2019 00:18:14 GMT Как известно, неприятные ошибки состоят по большей части из опечаток, off-by-one error, и cache invalidation. Это чисто технические, еще большая часть ошибок логические. Как именно компилятор Rust помогает с каждым из этих типов ошибок?<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#98 Tue, 27 Aug 2019 00:15:10 GMT Не защищая Rust, пример-то так себе. Вложив того и столько, чего и сколько в Chrome вложил Гугл, его можно было бы сделать точно таким же (во всяком случае не хуже) на любом языке, включая COBOL и РАПИРА, или совсем без оного - прямо в машинном коде, редактируя бинарник в ed.<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#97 Tue, 27 Aug 2019 00:09:06 GMT Надеюсь еще и вручную оптимизированная под конкретный размер кэшей конкретной линейки CPU конкретного производителя, с ассемблерными вставками, профайлингом доведенными до совершенства скорости работы на конкретном поколении конкретной линейки CPU конкретного производителя.<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#96 Mon, 26 Aug 2019 20:19:03 GMT Что-то твой всраст не помог огнелису стать нормальным браузером. Хром, на проклятых плюсах, все так и дает ему по морде.<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#95 Mon, 26 Aug 2019 18:48:34 GMT ARJ<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#94 Mon, 26 Aug 2019 13:33:45 GMT Вот обновленное сравнение юзерспейсных киллеров:<br><br>earlyoom: простой, лёгкий, стабильный. VmRSS меньше мегабайта, нагрузка на процессор околонулевая. С релиза 1.3 стал очень надежен (исправлено возможное убийство невиновных). Лучший выбор для домохозяек, которым не нужны лишние настройки, а нужна хорошая работа из коробки. Поддержка PSI обсуждается (https://github.com/rfjakob/earlyoom/issues/100 - автор давно собирался добавить поддержку PSI, но в последнее время засомневался в целесообразности этого. Проводятся работы по убеждению сенсея в необходимости добавления поддержки PSI). Оф Репа: https://github.com/rfjakob/earlyoom / Присутствует в репах Ubuntu 18.04+ и Debian 10+. Начиная с версии 1.3 могу смело рекомендовать его в качестве дефолтного киллера для десктопа. Буду лоббировать его в качестве дефолтного киллера для Федоры (zram они уже собрались включать по дефолту, для полного счястья не хватает earlyoom, обсуждение тут: https://pagure.io/fedora-workstation/issue/98 ).<br><br>nohang: явная и очень гибкая https://www.opennet.ru/openforum/vsluhforumID3/118253.html#93 Mon, 26 Aug 2019 11:57:06 GMT Если блокировка потока на выделении памяти приводить к непредсказуемому поведению, очевидно приложение написано криво. Логичным выводим из того, что new застопорился, должно быть понимание, что выделить память по какой-то причине не получается.<br>В любом случае автоматически прибивать - это самая крайняя мера. Её надо всеми возможными способами избегать.<br> https://www.opennet.ru/openforum/vsluhforumID3/118253.html#92 Mon, 26 Aug 2019 11:47:33 GMT &gt;заблочить на операции выделения памяти<br><br>Обычно это приводит к MemoryError и непредсказуемому поведению https://imgur.com/a/p9j67KA<br><br>SIGTERM обычно обрабатывается корректнее, чем ошибка выделения памяти.<br>