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

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

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

Я попытался объяснить выше.

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

А какая может быть «другая выгода»?

Тебе виднее. Если никакой другой выгоды (и никакой другой цели) у страничных приоритетов нет, то, наверное, для своей узкой цели они будут работать - в том случае, конечно, если working set trimming тоже будет подчиняться приоритетам. Будут ли они работать лучше, чем существующая система - большой вопрос.

Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно.

Дай ссылку на код. А то выше какой-то персонаж жаловался на то, что у него 16Г копируются 4 часа.

Это всё равно что запускать все процессы с приоритетами реального времени типа SCHED_FIFO

Похоже, да. И что в этом плохого? Если что, внутри SCHED_FIFO есть много приоритетов.

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

А ты в любом случае должен на что-то надеяться (TCB, ага). Как минимум - на ядро и login/DM, в случае сетевой машины - на ядро, SSH и шелл.

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации

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

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

Конечно. Но в твоем случае единственный критерий «здоровья» - размер (если не делать ручных настроек).

cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра,

И что? Я не предлагаю ее хачить. А подсистема VM увязана с другими подсистемами еще плотнее.

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

Реализация приоритетов будет таким кластерфаком с VM, что ее «перенос» будет написанием заново.

Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.)

Иерархия - это и про приоритеты тоже.

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

«If one of the ancestors goes over its limit, the reclaim algorithm reclaims from the tasks in the ancestor and the children of the ancestor».

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

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

Я попытался объяснить выше.

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

А какая может быть «другая выгода»?

Тебе виднее. Если никакой другой выгоды (и никакой другой цели) у страничных приоритетов нет, то, наверное, для своей узкой уели они будут работать - в том случае, конечно, если working set trimming тоже будет подчиняться приоритетам. Будут ли они работать лучше, чем существующая система - большой вопрос.

Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно.

Дай ссылку на код. А то выше какой-то персонаж жаловался на то, что у него 16Г копируются 4 часа.

Это всё равно что запускать все процессы с приоритетами реального времени типа SCHED_FIFO

Похоже, да. И что в этом плохого? Если что, внутри SCHED_FIFO есть много приоритетов.

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

А ты в любом случае должен на что-то надеяться (TCB, ага). Как минимум - на ядро и login/DM, в случае сетевой машины - на ядро, SSH и шелл.

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации

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

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

Конечно. Но в твоем случае единственный критерий «здоровья» - размер (если не делать ручных настроек).

cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра,

И что? Я не предлагаю ее хачить. А подсистема VM увязана с другими подсистемами еще плотнее.

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

Реализация приоритетов будет таким кластерфаком с VM, что ее «перенос» будет написанием заново.

Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.)

Иерархия - это и про приоритеты тоже.

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

«If one of the ancestors goes over its limit, the reclaim algorithm reclaims from the tasks in the ancestor and the children of the ancestor».