Выделение оперативной памяти для приложения/процесса

висит только браузер, но не оболочка рабочего стола

До такого прогресс еще не дошел.

До такого прогресс еще не дошел.

Надо работать )

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

Моя идея в том, чтобы защищать рабочий набор от давления со стороны других процессов:

• Сначала в порядке приоритетов, выставленных из юзерспейса.
• Если приоритеты равны, то в порядке потребляемой процессом памяти. Чем больше память потребляет процесс, тем сложнее ему затребовать себе новую.

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

Надо будет поразбираться с кодом.

у жирных процессов идёт в основном на анонимную память, такой режим работы не дружественен к ним и дружественен к процессам, имеющий малый объем анонимной памяти.

Из-за этого отзывчивость улучшается.

Думаю не совсем так.

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

Без защиты - либы вытесняются и снова считываются, растет IO, даже если нет свопа.

Да, это очевидная основа патча. Что-то я далеко от основы ушел в рассуждениях.

В uresourced защищается IO, MEM, CPU. В теории.

На практике защита io работаето только с btrfs.

uresourced пока защищает только процессы гном сессии.

На самом деле эффект от него есть, но не прям уж впечатляющ - prelockd и memavaild по-моему сильнее эффект давали.

сравнение плавности линий мониторам под стрессом https://gist.github.com/hakavlad/60575a8393ac6561904f46b0356ebfdb

Это еще немного о le9 https://gist.github.com/hakavlad/0c5e92f081a9c1a5a80ff827219efadd

Юзеры на десктопе обычно предпочитают низкие задержки. Система должна оставаться управляемой несмотря ни на что. Лучше потерять вкладку, чем повиснуть на неопределенный срок.

Для этого нужно не OOM делать, а выкидывать overcommit и чинить malloc/free чтобы он не рассчитывал на overcommit и освобождал память ядру. sbrk тоже выкинуть.

В Windows всё это ещё в Windows 1.0 было. В Haiku тоже с этим более-менее всё в порядке.

выкидывать overcommit и чинить malloc/free чтобы он не рассчитывал на overcommit и освобождал память ядру.

Шо, опять??

Не угомонишься с этой сломанной идеей?

выкидывать overcommit

Не выкидывать, а безусловно разрешать. Предпочитаю overcommit=1 и не имею проблем.

overcommit - это полезная абстракция. Запрет оверкоммита - опасная глупость.

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

Не угомонишься с этой сломанной идеей?

Это overcommit — defective by design. В нормальных десктопных ОС его нет. Без его выкидывания никакие OOM не помогут, программы в Линуксе будут виснуть и падать в случае нехватки памяти.

Линукс вообще предназначен для серверов и embedded, так что проблемы десктопа его разработчиков особо не волнуют. А на сервере задержки не так важны, важнее обработка запросов до конца.

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

Без его выкидывания никакие OOM не помогут, программы в Линуксе будут виснуть и падать в случае нехватки памяти.

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

Даже не знаю, на что тут можно возразить. Не возражать же всерьёз, если человек скажет, что Земля плоская.

никакие OOM не помогут

ООМ - это проблема, а не то, что должно помочь. При ООМ помогает ООМ киллер.

В нормальных десктопных ОС его нет

Линукс - универсальная ОС, а не десктопная.

Без его выкидывания никакие OOM не помогут, программы в Линуксе будут виснуть и падать в случае нехватки памяти

Это ложь.

overcommit - это полезная абстракция.

Overcommit — это МММ, только для памяти. Ядро выделяет не настоящую память (и даже не место в свопе), а билеты МММ. При обращении к такой памяти билеты могут превратиться в фантики и всё упадёт без возможности обработки. Если нет overcommit, то mmap/malloc вернёт NULL и программа сможет это корректно обработать (не открыть вкладку/окно) и работать дальше.

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

Можете объяснить как в системе с overcommit программа может идентифицировать и обработать нехватку памяти? Или прибивание случайных программ OOM киллером и/или длинные списки костылей с исключениями — это идеал устройства MM?

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

Я просто указал на корень проблемы, а не патчи с костылями, лечащими симптомы, а не болезнь.

При обращении к такой памяти билеты могут превратиться в фантики и всё упадёт без возможности обработки

Не упадет, а будет убито киллером - ядерным или юзерспейсным.

программа сможет это корректно обработать

Но делать этого, конечно, не будет.

программы в Линуксе будут виснуть и падать в случае нехватки памяти.

Только что проверил. С включённым свопом всё сбрасывается туда, если его отключить, ООМ-киллер убивает процесс, система стаёт снова работоспособной. 

Не упадет, а будет убито киллером - ядерным или юзерспейсным.

По сути одно и тоже. Отличаются только технические детали.

Но делать этого, конечно, не будет.

Нормальные программы делают. В Windows и Haiku например принято проверять выделенную память на NULL/std::bad_alloc и обрабатывать. В результате программы стабильно себя ведут в ситуации нехватки памяти. В Windows даже есть инструменты проверки программ, симулирующие нехватку памяти.

ООМ-киллер убивает процесс, система стаёт снова работоспособной

Где гарантия что OOM-киллер убьёт какой надо процесс? Или надо писать длинные списки исключений?

Поезд ушел, 2002 не вернуть. Если оверкоммит уже существует, то лучше его разрешать.

Поезд ушел, 2002 не вернуть.

В musl libc признают проблему и делают аллокатор памяти, совместимый с отсутствием overcommit и не использующий sbrk.

Для самых важных меняете oom_score_adj.

Для самых важных меняете oom_score_adj.

То есть костыли со списком исключений и индивидуальных настроек. в системах без overcommit всё просто работает без индивидуальных настроек.

Где гарантия что OOM-киллер убьёт какой надо процесс?

По крайней мере не убьет важные процессы, которые защищены через oom_score_adj.

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

см https://imgur.com/a/T68PAzD - оверкоммит запрещен, падают случайные мелкие процессы

в системах без overcommit

падают случайные прпоцессы

По крайней мере не убьет важные процессы, которые защищены через oom_score_adj.

А если в этом oom_score_adj есть процесс с утечкой памяти?

Где гарантия, что мелкие процессы не попадают

В системах без overcommit просто нет OOM-killer так что под него ничего не попадает.

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

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

см https://imgur.com/a/T68PAzD - оверкоммит запрещен, падают случайные мелкие процессы

Потому что в Линуксе на данный момент libc и много чего ещё прибито к overcommit.

системах без overcommit всё просто работает без индивидуальных настроек

Что просто работает? Только что забил память в винде — графический интерфейс просто стал, через 5 минут — картина та же.

Только что забил память в винде — графический интерфейс просто стал, через 5 минут — картина та же.

Проверил, у меня не встал после выделения всей памяти тестовой программой. Настройки подкачки неправильные?

Эта программа сделала ровным счётом абсолютно ничего, использовал https://docs.microsoft.com/en-us/sysinternals/downloads/testlimit. Настройки файла подкачки дефолтные.

Можете объяснить как в системе с overcommit программа может идентифицировать и обработать нехватку памяти?

Нехватка памяти — это условие, формируемое ядром. (Или околоядерными демонами, которые управляют механизмами выделения памяти.) Вот когда ядро решит, что «всё, нехватка памяти», тогда, значит, в системе нехватка памяти.

Вон ядро линукс неверно формирует такое условие и слишком поздно понимает, что памяти нет, а иногда вообще этого не понимает. Но имеет эта проблема отношение к оверкоммиту? Никакого.

При чем тут прикладная программа?

Или прибивание случайных программ OOM киллером и/или длинные списки костылей с исключениями — это идеал устройства MM?

Прибивание случайных программ — то то, что происходит на системе без оверкоммита.

Я просто указал на корень проблемы, а не патчи с костылями, лечащими симптомы, а не болезнь.

Вы пришли с какими-то своими фантазиями. Проблема трешинга файловых страниц может быть легко повторена на системе с выключенным оверкоммитом. Поставьте подкачку на гигов 50 на HDD, запустите десяток tail /dev/zero и наслаждайтесь зависшим компьютером.

В Windows всё это ещё в Windows 1.0 было. В Haiku тоже с этим более-менее всё в порядке.

Ничего, что в 16-битном и 32-битном мире исчерпать логическое адресное пространство — вовсе не дофига делов? Разумеется программы должны как можно более корректно обрабатывать отказ на выделение памяти.

Какое отношение внутренняя кухня программы имеет к ядру?

А если в этом oom_score_adj есть процесс с утечкой памяти?

А если в ядре утечка памяти?

Мы неизбежно закладываемся на то, что чем более компонент системный, тем он надёжнее и предсказуемее. Иначе какой он к черту системный.

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

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

А если случайно или специально написан некорректно, то он может в цикле выделять и освобождать память крупными блоками и последовательно ронять все другие процессы. «З — защита» и «У — управление ресурсами».

В системах без overcommit просто нет OOM-killer так что под него ничего не попадает.

И поэтому злонамеренный процесс может безнаказанно жрать память. Браво.

Вот когда ядро решит, что «всё, нехватка памяти», тогда, значит, в системе нехватка памяти.

У программы должен быть шанс это обработать и продолжить работу пока не пришёл OOM-killer. Я так понимаю с включённым overcommit это сделать невозможно в принципе.

Вон ядро линукс неверно формирует такое условие и слишком поздно понимает, что памяти нет, а иногда вообще этого не понимает. Но имеет эта проблема отношение к оверкоммиту? Никакого.

Ну тогда это баг ядра и это надо чинить.

Мы неизбежно закладываемся на то, что чем более компонент системный, тем он надёжнее и предсказуемее. Иначе какой он к черту системный.

Может быть важная не системная программа, падение которой нежелательно. Но не настолько нежелательно как падение системных компонентов.

И поэтому злонамеренный процесс может безнаказанно жрать память. Браво.

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

Может быть важная не системная программа, падение которой нежелательно. Но не настолько нежелательно как падение системных компонентов.

Я не распарсил, но как настроите, так и будет.

Если вам важна программа расчёта, которая работает 5 часов и потребляет 25 ГБ оперативки из имеющихся 32, то так и нужно объяснить системе, что в случае чего можно убивать браузер, текстовый редактор и всю остальную прикладуху, а не эту программу.

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

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

Как он будет работать, если при попытке запуска он получает 0 из malloc() и честно завершается как всякая незлонамеренная программа? Будьте последовательны. Кстати, а кто его запустит?

У программы должен быть шанс это обработать и продолжить работу пока не пришёл OOM-killer.

См. выше про предварительный SIGTERM перед SIGKILL из юзерспейсного киллера.

Я не знаю, сделано ли это в какой-нибудь из киллеров, но сделать не дофига делов:

• Сначала рассылать уведомление через dbus.
• Через время — SIGTERM.
• И еще через время — SIGKILL.

Ну тогда это баг ядра

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

Если вам важна программа расчёта, которая работает 5 часов и потребляет 25 ГБ оперативки из имеющихся 32, то так и нужно объяснить системе

То есть опять костыли с правкой конфигов.

Как он будет работать, если при попытке запуска он получает 0 из malloc() и честно завершается как всякая незлонамеренная программа?

В Haiku простой диспетчер задач запущен всегда, просто его окно скрыто. При его вызове показывается скрытое окно.

Можно зарезервировать память для системных процессов и не давать её выделять обычным процессам. Вроде бы в Линуксе так можно сделать.

См. выше про предварительный SIGTERM перед SIGKILL из юзерспейсного киллера.

Я так понимаю он предполагает завершение программы с сохранением данных, а не продолжение её работы. Тогда это не то что нужно. Или я ошибаюсь?

Сначала рассылать уведомление через dbus.

Было бы неплохо, но реализации этого я пока не видел.

То есть опять костыли с правкой конфигов.

Конфиги для того и придуманы, чтобы настраивать работу программы.

Конфиги для того и придуманы, чтобы настраивать работу программы.

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

Компьютер придуман для автоматизации задач. Вот вы дали задачу — пусть работает какая-то требовательная программа, указали ему не убивать её первым делом, всё, дальше он сам. Вы, может, хотите, чтобы он сам всё понимал, сам решал, что для конкретного человека важно, но, увы, такого пока не изобрели.

То есть опять костыли с правкой конфигов.

Нет, ска, компьютер должен сам понять твои желания! Купи Яндекс-колонку с Алисой, ей не нужны конфиги, она голосом разговаривает!

Я так понимаю он предполагает завершение программы с сохранением данных, а не продолжение её работы. Тогда это не то что нужно. Или я ошибаюсь?

Как можно продолжить то, для чего физически нет памяти?

Я предложил другое решение, см. выше. Тормозить процесс и выгружать страницы, пока админ не придёт и не разберётся. Реализовать пока никто не реализовал. Ни для одной ОС.

Как можно продолжить то, для чего физически нет памяти?

Освободить память (внутренние кеши, открытые вкладки и т.п.) и продолжить работу. В Обероне для этого даже специальный API предусмотрен (Kernel.Reducer).

Освободить память (внутренние кеши, открытые вкладки и т.п.) и продолжить работу.

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

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

Насколько оперативно? Может станет ложным, а может не станет. Это не надёжно, нужен протокол между программой и OOM-killer дающий гарантии что не прибьют программу, корректно реагирующую на сообщения протокола.

вот смотри, у меня есть программа (скрипт):

#!/bin/bash
echo PENIS

Как мне заставить его использовать все мои 16 гигов оперативки?

Вот у тебя аналогичный вопрос.

Насколько оперативно?

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

Это не надёжно, нужен протокол между программой и OOM-killer дающий гарантии что не прибьют программу, корректно реагирующую на сообщения протокола.

Чтобы она им злоупотребляла? Спасибо, не надо.

слишком поздно понимает, что памяти нет

это легко исправить, и оверкоммит ни при чем

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

Большинство админов локалхоста ничего не настраивают и не знают как настраивать. Потом ругаются какой Линукс кривой что в нём всё висит и падает, а в Windows и Mac OS всё из коробки работает без настроек.

Чтобы она им злоупотребляла?

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

Большинство админов локалхоста ничего не настраивают и не знают как настраивать.

Ты правда такой больной? Если есть сложное поведение, у него обычно есть настройки. У настроек есть дефолтные значения.

Нет, всё-таки вы вместе с Мойшей напроситесь на игнор. Я принципиально не хочу никого игнорировать, но читать эти потоки бреда и тупняка уже нет никаких сил. Вали уже в свою прекрасную Гайку с концами. Оставь нас убогих тут решать наши убогие вопросы в кривом глючном ляликсе.

Потом ругаются какой Линукс кривой что в нём всё висит и падает, а в Windows и Mac OS всё из коробки работает без настроек.

УМВР, ЧЯДНТ? 4.2., нихрена в вашем виндовозе не работает. Ну и так далее, подставь мемы по вкусу.

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

Ждём-с.

echo PENIS

А вы все о пенисах мечтаете … Хоть бы вас кто-нибудь отжарил уже … Шли бы вы на гей ру со своими фантазиями.

Владимир 123

А вы там админ?