Просто оставлю это здесь: Игра в supertux2 с множественными `tail /dev/zero` в фоне без зависаний

а я вот за последний год под линуксом уже пару десяток раз делал хардресет, т.к. жирнофокс (всегда жирнофокс) вешал систему так, что переключение на другую консоль не работало, пусть и с задержками

$ ps -e -O stime | grep firefox
17053 сен28  S ?     08:19:43 /usr/bin/firefox
$ free -m
              total        used        free      shared  buff/cache   available
Mem:          16013        3643        8687         237        3682       11809
Swap:          3071         187        2884

ЧЯДНТ?

не знаю, баг плавающий, проявляется редко, всегда на тяжёлых и кривых сайтах с видео или кучей скриптов

https://src.fedoraproject.org/rpms/memavaild

memavaild опакечен для Fedora/CentOS 8 и скоро появится в репах.

Compiling Linux 5.4 with make -j512, MemTotal=9.6G, swap om zram https://youtu.be/dPw5c4rYAdE

Просто оставлю это здесь: Игра в supertux2 с множественными tail /dev/zero в фоне без зависаний

А если в Ведьмак 3?)

Ведьмака тестировать не доводилось.

Есть только supertux + компиляция Linux через make -j512 https://youtu.be/dPw5c4rYAdE

Не так ссылка. Вот supertux + -j512 https://youtu.be/nSCT_zZHYYQ - c с сильными фризами, но без потери управления

Кстати, а что изменится, если сжимать в zram не нули а /dev/urandom? Просто поток нулей жмётся в ноль почти любым алгоритмом, а вот реальные приложения хорошо если в 3 раза.

Зависает это громко сказано.

что изменится, если сжимать в zram не нули а /dev/urandom

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

Нули, разумеется, лучший кейс, жмутся и в сотни раз и быстро.

реальные приложения хорошо если в 3 раза

В 2-4 раза. браузеры в 3-4 раза жмутся, если забивать память вкладками

supertux + -j512 https://youtu.be/nSCT_zZHYYQ - вот тут в три раза сжатие было примерно, при компиляции ядра

Зависает это громко сказано.

Ну у кого как. На ядре 49 на дебиан гуй зависал от tail /dev/zero, на 54 не зависает.

Если процессов больше, чем ядер процессора, то процессор больше будет тратить ресурсов на переключение контекста, нежели на работу этих процессов. Предполагаю, если сделать 512 процессов внутри которого будет

nop
sleep 1

Или какой-нибудь

push rax
mov rax,1
pop rax

То тормозить будет точно так же, как с compile kenrnel -j512. Так что такая синтетика мало применима. А вот то, что в тестах используется 2д игра, которая полностью в памяти хранится. Если взять какую-то игру, которая пишет в память и читает из памяти, вот тогда тормоза будут и с make -j2

По крайней мере гуй в память похоже что почти не пишет, так что гую угрозы нет.

Сейчас мы можем:

• закреплять в памяти код гуя и приложений

• запуская фоновые жирные процессы в отдельном слайсе, можно с помощью настроек memavaild выталкивать этот слайс в своп в первую очередь - как раз это и применяется на последних демо, где компиляция с j512 и почти безфризовая игра с 12 потоками tail.

Я согласен, что произведена огромная работа с конкретными результатами! Потестируй это всё на 3д играх или придумай какую-то задачу, который нагружает cpu + ram в самой игре, чтобы не 2д-шку гонять, а более-менее вменяемую игру

Наконец-то кто-то примерно доходчиво объяснил. Надо будет юзнуть. У меня за счет zram отзывчивость еще как-то держится.

А есть ссылки на описание и обсуждение этого самого трюка с отключением отбрасывания чего то, а то по сылке чувак просто жалуется, но без подробностей.

Кстати, любопытно было бы узнать почему в ядре сделано именно так. А то все недовольны, все кричат что оно кривое. Но почему? Дисковая подсистема как то сама собой вылечилась.

вылечилась

от чего? если тормозную флэшку записывать - точно так же фризит всё. по крайней мере так было, не так давно, когда я это делал не прописывая исправляющие это параметры

А есть такая опция «тот, кто запросил выделить больше всего памяти за последнюю секунду?»

Не представляю что там надо делать чтобы заставить фризить. Как бы теоретически да, фризит. Но только тех, кто непосредственно сейчас шлёт io на эту самую тормозную флешку.

фризило всю систему, которой на этой флешке делать вообще нечего

RPI3, 942М оперы, 120Г свопа на ссд, 400М zram, ядро 4.4. Мышка фризится, переключение окон и консолей замедляется до 5-10 секунд, htop после запуска работает довольно шустро. Через 4-5 минут tail падает достигнув предела 32 битной адресации.

Не, играть или сёрфить конечно не получится, но система достаточно отзывчива чтобы не задумываться о решении этой проблемы.

Вот когда увижу вживую, тогда поверю.

самому торвальдсу не веришь? он про такое жаловался

ну или про что-то похожее

Во первых он - тролль. А во вторых, это могло быть ещё в 90-х, когда реально глючило.

он - тролль

намекаешь будто ты - нет

в 90-х

нет, не настолько давно

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

Можно использовать, но не в любой задаче и не с оверхедом в 400% в одном процессе. Гимп вот отлично свопит, это реально в разы повышает возможности для манёвра. Браузеры свопятся до 200% без проблем. А уж всякие читалки pdf и смотрелки фото, пусть себе вытесняются и лежат неделями до востребования.

Немного не так, в лучшем случае это даёт принципиальную возможность выполнить задачу вот на этом железе, а не сбегать и купить новое.

Мне кажется вы ударяетесь в другую крайность. Под задачу в 20гб стоит 48, так, на всякий случай.

Файерфокс это сейчас в принципе самый приспособленный к свопингу браузер. Вы что то делаете не так.

Это конечно было плохой идеей, но ложиться всё плавно начало почти сразу, как только понадобился своп. Надо предположить из за какого то однопоточного бутылочного горлышка, куда начали стучаться пара десятков конкурентов. Можно подобрать задачу так, чтобы потоков не более 2 на ядро, а вот в своп хотя бы 3-5 гигов?

новейшее оружие в борьбе за отзывчивость при нехватке памяти

Какие только костыли не изобретают линуксоиды, лишь бы не избавляться от проблемы. ☺

Наглядно: https://ibb.co/Ct4wHxC - как меняется давление памяти при включении memavaild в нагруженной циклами tail /dev/zero системе. memavaild уже лежит в репах Fedora 31-32.

swap on ssd, 2 потока циклов tail, давление full mem и io в среднем 60-65, с memavaild - 30-35.

пока при правильном применении memavaild дает лучший эффект, и не расходует память на избыточные блокировки по сравнению с prelockd.

1. Добавляешь в ~/.bashrc:

alias idle-run='systemd-run --user --slice=idle.slice -t $SHELL'

Далее для запуска жирных процессов выполняешь в терминале idle-run, и далее процессы в этом терминале будут выполняться в отдельном слайсе, который первоочередно будет вытесняться в своп при помощи memavaild. Альтернатива - повесить на горячую клавишу запуск терминал сразу через systemd-run, команда примерно такая: systemd-run --user --slice=idle.slice xterm.

2. Для соответствующей настройки memavaild нужно добавить в конфиг следующую строку, при необходимости поправив UID пользователя:

@LIMIT  CGROUP=user.slice/user-1000.slice/user@1000.service/idle.slice  MIN_PERCENT=5  MAX_PERCENT=100  FRACTION=0.1

https://youtu.be/DsXEWvq60Rw - вообще без фризов при свопе на HDD выполняется tail /dev/zero.

3. И, разумеется, требуется systemd с unified cgroup hierarchy для работы memavaild. Unified cgroup hierarchy is enabled by default on Fedora 31+. On other distros pass systemd.unified_cgroup_hierarchy=1 in the kernel boot cmdline.

Файерфокс это сейчас в принципе самый приспособленный к свопингу браузер.

пруфца бы

настолько много жрёт, что с ним проще всего увидеть своппинг?

Порождает столько процессов, сколько ты ему скажешь. А сколько конкурирующих процессов проще свопить, 2 или 20? А у кого оверхед на порождение 20 вкладок будет ниже, у 2 или у 20 процессов?

сколько конкурирующих процессов проще свопить, 2 или 20?

что за «проще свопить»? если память всех этих процессов активно используется - свапить будет бесконечно туда обратно без какого-либо прогресса. от количества это никак не зависит

у кого оверхед на порождение 20 вкладок будет ниже, у 2 или у 20 процессов?

у 2x разумеется, это же базовые вещи

настолько много жрёт, что с ним проще всего увидеть своппинг?

Да, течёт только в путь. Вот опять 25гб видеопамяти сожрал, хотя у меня всего 6, значит 19 из свопа :(

https://i.imgur.com/N6hnyNx.png

Чего? Винда наглухо виснет минут на пять, если тупо много окон пооткрывать.

Кто-нибудь с Ryzen 9 3900X и 64 оперативы проведите этот стресс-тест и посрамите колхозные потуги ТСа.

если память всех этих процессов активно используется - свапить будет бесконечно туда обратно без какого-либо прогресса

Но она же не бесконечно свопится, это же не хромоклон, где каждая вкладка должна поддерживать минимальную активность в районе где то 20-40М на вкладку. Здесь вкладка отрисовывается и спокойно падает в своп до востребования.

у 2x разумеется, это же базовые вещи

Именно. И фокс может работать с малым оверхедом.

https://ibb.co/Ntq3WVv

Оцените всю вычислительную мощь, стоящую за этим файерфоксом 60-еср. И тем не менее, 30 произвольных вкладок, которые можно отправлять на отрисовку по 4-5 штук за раз на 2-х потоках контента до появления критичных тормозов. Ещё второе окно со всякой мелочью и аптайм файерфокса на 10 минут меньше, чем у системы. Т.е. он уже полмесяца просто живёт в свопе не вылезая. При этом функционал сохраняется и в течении 10-120 секунд можно продолжить работу с любой из влкадок. Для сравнения хромиум здесь же практически лежал и непрерывно свопился уде при 15-20 штуках.

Да, я знаю что пруфы надо бы предоставлять как видео, но это технически сложно, потому что это малина3 и она может писать скринкаст только на 2 фпс, и у меня нет аккаунтов, куда я мог бы выложить видео.

Только блин в винде можно выделить больше видеопамяти чем физически существует и запусть по несколько копий процессов, которыые не позволяют запускать по несколько копий себя.

ну и печь этот ваш арм, на x86 26-27° в браузере