История изменений

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

А что в этом странного?

Не знаю насчет «многих», но, в любом случае, меня интересует случай, когда это _не_ так - т.е. когда память расходуется группой близких по размеру процессов. Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А какая может быть «другая выгода»? Моя цель именно обеспечение «интерактивного отклика». Конкретно в случае Linux — обеспечение хоть какого-то отклика. Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно. Достаточно его просто запустить, подождать несколько секунд, затем нажать Ctrl+C — и можно идти пить чай на 10-15 минут. Примерно столько понадобится, чтобы сигнал прерывания дошел «куда надо». Сам понимаешь, если такой процесс запущен не в foreground-е активного терминала, то поможет только аппаратный сброс.

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

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

Если говорить об эксплуатационных характеристиках, то приоритизация рабочих наборов лучше иерархии cgroups в следующем:

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации. Один и тот же vim, запущенный одним и тем же пользователем в том же самом терминале может быть либо очень важной задачей, если в нём администратор просматривает и правит конфигурационные файлы, и тот работает исправно, или же низкоприоритетной задачей, если в результате бага он выжрал 4 гигабайта и начал по ним активно ходить туда-сюда. Любой процесс, включая и административные, может «протечь» от багов, подвергнуться атаке, быть случайно запущен в такими параметрами или в таком контексте, которые приводят к выжиранию памяти. Пока в системе остаются здоровые средства взаимодействия с пользователем (и в частном случае с — администратором), они должны продолжать работать вне зависимости от состояния других процессов.
cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра, и привязанная конкретно к линуксу. При чем подверженная постоянным доработкам и переделкам именно в силу своей запутанности. Приоритеты рабочих наборов — узкоспецилизированный механизм, принадлежащий одной конкретной подсистеме и ограничивающийся ею. Потенциально его можно перенести на другие unix-подобные системы для улучшения их эксплуатационных свойств, в то время как унификация механизмов контейнеризации между ядрами вряд ли возможна в обозримом будущем.
Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.) Мы можем отрегулировать hard и soft лимиты, swappiness и... кажется, больше ничего. Это значит, что нам придётся велосипедить демон который будет эмулировать приоритеты поверх системы лимитов — какой-то троллейбус из хлеба получился.

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

А что в этом странного?

Не знаю насчет «многих», но, в любом случае, меня интересует случай, когда это _не_ так - т.е. когда память расходуется группой близких по размеру процессов. Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А какая может быть «другая выгода»? Моя цель именно обеспечение «интерактивного отклика». Конкретно в случае Linux — обеспечение хоть какого-то отклика. Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно. Достаточно его просто запустить, подождать несколько секунд, затем нажать Ctrl+C — и можно идти пить чай на 10-15 минут. Примерно столько понадобится, чтобы сигнал прерывания дошел «куда надо». Сам понимаешь, если такой процесс запущен не в foreground-е активного терминала, то поможет только аппаратный сброс.

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

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

Если говорить об эксплуатационных характеристиках, то приоритизация рабочих наборов лучше иерархии cgroups в следующем:

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации. Один и тот же vim, запущенный одним и тем же пользователем в том же самом терминале может быть либо очень важной задачей, если в нём администратор просматривает и правит конфигурационные файлы, и тот работает исправно, или же низкоприоритетной задачей, если в результате бага он выжрал 4 гигабайта и начал по ним активно ходить туда-сюда. Любой процесс, включая и административные, может «протечь» от багов, подвергнуться атаке, быть случайно запущен в такими параметрами или в таком контексте, которые приводят к выжиранию памяти. Пока в системе остаются здоровые средства взаимодействия с пользователем (и в частном случае с — администратором), они должны продолжать работать вне зависимости от состояния других процессов.
cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра, и привязанная конкретно к линуксу. При чем подверженная постоянным доработкам и переделкам именно в силу своей запутанности. Приоритеты рабочих наборов — узкоспецилизированный механизм, принадлежащий одной конкретной подсистеме и ограничивающийся ею. Потенциально его можно перенести на другие unix-подобные системы для улучшения их эксплуатационных свойств, в то время как унификация механизмов контейнерезации между ядрами вряд ли возможна в обозримом будущем.
Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.) Мы можем отрегулировать hard и soft лимиты, swappiness и... кажется, больше ничего. Это значит, что нам придётся велосипедить демон который будет эмулировать приоритеты поверх системы лимитов — какой-то троллейбус из хлеба получился.

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

А что в этом странного?

Не знаю насчет «многих», но, в любом случае, меня интересует случай, когда это _не_ так - т.е. когда память расходуется группой близких по размеру процессов. Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А какая может быть «другая выгода»? Моя цель именно обеспечение «интерактивного отклика». Конкретно в случае Linux — обеспечение хоть какого-то отклика. Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно. Достаточно его просто запустить, подождать несколько секунд, затем нажать Ctrl+C — и можно идти пить чай на 10-15 минут. Примерно столько понадобится, чтобы сигнал прерывания дошел «куда надо». Сам понимаешь, если такой процесс запущен не в foreground-е активного терминала, то поможет только аппаратный сброс.

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

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

Если говорить об эксплуатационных характеристиках, то приоритизация рабочих наборов лучше иерархии cgroups в следующем:

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации. Один и тот же vim, запущенный одним и тем же пользователем в том же самом терминале может быть либо очень важной задачей, если в нём администратор просматривает и правит конфигурационные файлы, и тот работает исправно, или же низкоприоритетной задачей, если в результате бага он выжрал 4 гигабайта и начал по ним активно ходить туда-сюда. Любой процесс, включая и административные, может «протечь» от багов, подвергнуться атаке, быть случайно запущен в такими параметрами или в таком контексте, которые приводят к выжиранию памяти. Пока в системе остаются здоровые средства взаимодействия с пользователем (и в частном случае с — администратором), они должны продолжать работать вне зависимости от состояния других процессов.
cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра, и привязанная конкретно к линуксу. При чем подверженная постоянным доработкам и переделкам именно в силу своей запутанности. Приоритеты рабочих наборов — узкоспецилизированный механизм, принадлежащий одной конкретной подсистеме и ограничивающийся ею. Потенциально его можно перенести на другие unix-подобные системы для улучшения их эксплцатационных свойств, в то время как унификация механизмов контейнерезации между ядрами вряд ли возможна в обозримом будущем.
Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.) Мы можем отрегулировать hard и soft лимиты, swappiness и... кажется, больше ничего. Это значит, что нам придётся велосипедить демон который будет эмулировать приоритеты поверх системы лимитов — какой-то троллейбус из хлеба получился.

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

А что в этом странного?

Не знаю насчет «многих», но, в любом случае, меня интересует случай, когда это _не_ так - т.е. когда память расходуется группой близких по размеру процессов. Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А какая может быть «другая выгода»? Моя цель именно обеспечение «интерактивного отклика». Конкретно в случае Linux — обеспечение хоть какого-то отклика. Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно. Достаточно его просто запустить, подождать несколько секунд, затем нажать Ctrl+C — и можно идти пить чай на 10-15 минут. Примерно столько понадобится, чтобы сигнал прерывания дошел «куда надо». Сам понимаешь, если такой процесс запущен не в foreground-е активного терминала, то поможет только аппаратный сброс.

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

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

Если говорить об эксплуатационных характеристиках, то приоритизация рабочих наборов лучше иерархии cgroups в следующем:

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации. Один и тот же vim, запущенный одним и тем же пользователем в том же самом терминале может быть либо очень важной задачей, если в нём администратор просматривает и правит конфигурационные файлы, и тот работает исправно, или же низкоприоритетной задачей, если в результате бага он выжрал 4 гигабайта и начал по ним активно ходить туда-сюда. Любой процесс, включая и административные, может «протечь» от багов, подвергнуться атаке, быть случайно запущен в такими параметрами или в таком контексте, которые приводят к выжиранию памяти. Пока в системе остаются здоровые средства взаимодействия с пользователем (и в частном случае с — администратором), они должны продолжать работать вне зависимости от состояния других процессов.
cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра, и привязанная конкретно к линуксу. При чем подверженная постоянным доработкам и переделкам именно в силу своей запутанности. Приоритеты рабочих наборов — узкоспецилизированный механизм, принадлежащий одной конкретной подсистеме и ограничивающийся её. Потенциально его можно перенести на другие unix-подобные системы для улучшения их эксплцатационных свойств, в то время как унификация механизмов контейнерезации между ядрами вряд ли возможна в обозримом будущем.
Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.) Мы можем отрегулировать hard и soft лимиты, swappiness и... кажется, больше ничего. Это значит, что нам придётся велосипедить демон который будет эмулировать приоритеты поверх системы лимитов — какой-то троллейбус из хлеба получился.