LINUX.ORG.RU

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

 


14

2

Собственно: https://youtu.be/fPnbnNX9CPE

Система на HDD, Debian 9 Mate, MemTotal=10GB, swap on zram (disksize=14GB). memavaild, prelockd и nohang-desktop работают в фоне и помогают сохранять отзывчивость несмотря ни на что.

https://github.com/hakavlad/nohang

https://github.com/hakavlad/prelockd

https://github.com/hakavlad/memavaild

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

Спрашивайте ответы.

★★★

Ответ на: комментарий от anonymous

Что поделать, 7Вт и 45нм кажется. В следующей версии даже пришлось об охлаждении подумать.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Это детская херня. Нагрузка, на которой у меня почти гарантированно начинались тормоза в лисе - 200 вкладок с видео в фоне.

next_time ★★★★★
()
Ответ на: комментарий от kirill_rrr

Можно использовать

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

gremlin_the_red ★★★★★
()
Ответ на: комментарий от gremlin_the_red

нельзя использовать свап, как дополнительную память

Если очень хочется, то можно.

два варианта — или бесконечный (почти) свопинг, или убийство процесса. И ни в одном из этих вариантов ты свой софт собранным не увидишь

В первом варианте увижу. Без свопа - точно не увижу, если нет памяти для завершения сборки.

hakavlad ★★★
() автор топика
Ответ на: комментарий от next_time

пару десяток раз делал хардресет

Можно просто выполнять Alt+SysRq+K для перезапуска сессии. Тогда перезагрузка обычно не требуется.

anonymous
()
Ответ на: комментарий от kirill_rrr

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

Ну да, один tail /dev/zero не вешает наглухо. А вот компиляция webkitgtk - вполне:

30+ minute hang

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TCIVNXEHWENIWQT35XX6PRC7ZAYTRDGQ/

anonymous
()
Ответ на: комментарий от anonymous

поржал с ламерских советиков там

anonymous
()
Ответ на: комментарий от anonymous

Странно, не помню каких либо вопросов со сборкой браузерных движков в 8Гб оперативки. Возможно всё дело в том, что я пытался их собрать, а не симулировать критическую перегрузку с невозможностью разруливания ситуации. Результат: всё таки оно сдохло. Проблема вставания раком видится мне в том, что реального свопа всё таки не было. И у ядра соответственно не было возможности выделить юзеру 10М, необходимых для запуска htop в консоли чтобы в разумные сроки прервать этот бардак.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

ну или хотя бы в восемь, как у проца по ссылке там

anonymous
()
Ответ на: комментарий от anonymous

Андроидопроблемы. Да, там всё ещё фат32. Да, там mtp, который работает в полнолуние на пятницу 13-е. Да, там нельзя монтировать. Да, там нет демонов для расширивания папок, нет ssh и проблемы с адекватным софтом.

Но тем не менее, даже тогда не обязательно долбиться головой об криволапый драйвер непонятно чего, который по сути не работает, как не работает юзерспейсный драйвер exfat. Потому что адекватные драйвера не пытаются хранить всю файловую операцию на потенциально сотни гигабайт в оперативной памяти.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

В данном случае сборка в 2-4 потока вероятно окажется быстрее. А раз она быстрее, значит и собирать надо в 2-4 потока. Что поделать, всегда есть ограничения и учитывать надо самый дефицитный ресурс. Если конечно вас интересует результат, а не стресс-тест.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

демо возможностей memavaild: сохранение отзывчивости при интенсивнейшем своппинге

hakavlad ★★★
() автор топика

Любопытные костылики. Но прежде чем тыкать, до Linux 5.8 обновимся, там появилась возможность выкручивать vm.swappiness до 200. Наверняка сильно уменьшит вытеснение дискового кэша под нагрузкой, хотя под сильной, конечно, не поможет, уж лучше впрямь локать.

Только вот где?..

root@localhost:~# cgget /user.slice/user-1000.slice/session-20.scope|&grep high
root@localhost:~# 

Это вот для чего с systemd.unified_cgroup_hierarchy=1 грузиться нужно?

mertvoprog
()
Ответ на: комментарий от gremlin_the_red

надо идти в магазин за памятью

Не всем этот вариант подходит.

Вылезайте из криокамеры, zram реально позволяет в пару раз увеличить доступную память без существенных просадок производительности ;)

Вы напоминаете фанатиков, которые в своё время кричали, что виртуальную память надо ограничивать размером физической, а впрок её выделяет только говнософт ;) Благо, хоть они вымерли наконец вроде.

mertvoprog
()
Ответ на: комментарий от kirill_rrr

может писать скринкаст только на 2 фпс

Что мешает экран на камеру снять? ;)

и у меня нет аккаунтов, куда я мог бы выложить видео

???? 0x0.st и прочие файлопомойки типа MediaFire регистрации не требуют.

mertvoprog
()
Ответ на: комментарий от mord0d

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

mertvoprog
()
Ответ на: комментарий от hakavlad

Непонятно лишь, зачем эти полумеры, нет бы безлимит сразу ;)

mertvoprog
()

Игра в supertux

Супертукс - пингвин отважный
я играл в него не дважды

Владимир

anonymous
()

Кхм, а почему prelockd сожрал аж 293 МБ? Так и положено, он всю память чужих процессов, которую лочит, shared с собой делает?

mertvoprog
()
Ответ на: комментарий от anonymous

Вам hd не завезли, да?

@bq:20:07:26:/tmp/dl$ echo 144p|hd
00000000  31 34 34 70 0a                                    |144p.|
00000005
@bq:20:07:30:/tmp/dl$ echo 144р|hd
00000000  31 34 34 d1 80 0a                                 |144...|
00000006

При чём здесь рубли?

mertvoprog
()
Ответ на: комментарий от mertvoprog

144p снимали

ещё и вертикально, небось, засранец? надейся, чтоб я тебя лично не встретил

anonymous
()
Ответ на: комментарий от anonymous

Мы не снимали, но другие да ;)

Удобно, кстати, смотреть на старых мобильниках, не надо с акселерометром воевать. Как сняли, так и воспроизводится.

mertvoprog
()
Ответ на: комментарий от mertvoprog

Мы вообще 144p снимали ;)

При чём здесь рубли?

Я подумал, что вы 144 рубля сняли в банкомате и позавидовал вашему благосостоянию :(

Владимир

anonymous
()
Ответ на: комментарий от anonymous

А это интересный номер был бы, кстати. Банкоматы где-то мелочь выдают?

mertvoprog
()
Ответ на: комментарий от mertvoprog

Так и положено, он всю память чужих процессов, которую лочит, shared с собой делает?

Да, держит в памяти либы расшаренными.

hakavlad ★★★
() автор топика
Ответ на: комментарий от mertvoprog

Локи отменятся. Отзывчивость при нехватке памяти может сразу упасть.

hakavlad ★★★
() автор топика
Ответ на: комментарий от hakavlad

а где игра в пингвин?
тест не релевантный :)

Minona ★★☆
()

Supertax отнюдь не показатель, попробуй tuxtacer

anonymous
()
Ответ на: комментарий от crypt

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

в лучшем случае патч примут левые ядра типа zen или pf. Для приянтия в основную ветвь нужно пройти ад и бюрократию.

anonymous
()
Ответ на: комментарий от gremlin_the_red

Если на машине с 4гб пытаться компилять софт, которому для сборки нужно 16 гиг, то тут ошибка не в системе, а в днк

с -j1 вполне соберется

У системы тут только два варианта — или бесконечный (почти) свопинг, или убийство процесса. И ни в одном из этих вариантов ты свой софт собранным не увидишь.

Вовсе не бесконечный, если своп не на hdd. Успешно собирал хромиум с -j32 На 8 гигах рам, оставив сборку на ночь.

anonymous
()
18 апреля 2021 г.

«Как из Linux набором костылей сделать iOS».

zemidius
()
26 декабря 2021 г.
Ответ на: комментарий от EXL

Неужели теперь Linux при нехватке ресурсов будет реагировать нормально, как то же ядро NT

Если говорить о ядре, то нет: мейнлайовые mm-мейнтейнеры признают проблему, но не готовы что-либо делать для ее решения.

Ну и ответа Михала Хоко - это вообще пушка:

Really, you should realize that such a knob would become carved
into stone as soon as wee merge this and we will need to support it
for ever! It is really painful (if possible at all) to deprecate any
tunable knobs that cannot be supported anymore because the underlying
implementation doesn't allow for that.  So we would absolutely need to
be sure this is the right approach to the problem.  I am not convinced
about that though.

How does the admin know the limit should be set to a certain
workload? What if the workload characteristics change and the existing
setting is just to restrictive? What if the workload istrashing over
something different than anon/file memory (e.g. any other cache that we
have or might have in the future)?

As you have pointed out there were general recommendations to use user
space based oom killer solutions which can be tuned for the specific
workload or used in an environment where the disruptive OOM killer
action is less of a problem because workload can be restarted easily
without too much harm caused by the oom killer.
Please keep in mind that there are many more different workloads that
have different requirements and an oom killer invocation can be really
much worse than a slow progress due to ephemeral, peak or even longer
term trashing or heavy refaults.

https://lore.kernel.org/lkml/YbcNUEZ08lmbv0RM@dhcp22.suse.cz/

Буквально:

  • админы не смогут подобрать оптимальное значение для новой ручки, поэтому лучше ее не добавлять вообще;
  • а вдруг мы когда-нибудь найдем лучшее решение проблемы, и ручка окажется не нужна?
  • используйте earlyoom/oomd, мы не хотим брать на себя ответственность за решение проблемы на уровне ядра!

Признают проблему на словах, но менять ничего не собираются.

hakavlad ★★★
() автор топика
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от anonymous

-j32 На 8 гигах рам

Зивоно-дебил, ты?

anonymous
()
Ответ на: комментарий от hakavlad

сделай вместо sysctl настройку в debugfs, или где там они не требуют сохранения совместимости

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.