Повысить эффект от nice

Есть две крайности — (псевдо)реалтайм и вытесняющая многозадачность. Дефолтное ядро стремится к первому, в то время как BFS, BFQ и sched_autogroup тяготеют ко второму. Собссно, и поведение nice отсюда разное (на вид).

А ты уверен, что тебе нужен nice, а не ionice?

Ну на BFS nice работал. А что, при высоком io может тормозить работа программ, например прокрутка страниц в браузере?

mkdir /sys/fs/cgroup/cpu/lowlevel                         # создать новую иерархию в cpu
echo 100 > /sys/fs/cgroup/cpu/lowlevel/cpu.shares # выдать ей ~10% от времени проца, дефолтное 1024

запуск:

runsmth
echo $! > /sys/fs/cgroup/cpu/lowlevel/tasks # ну если тут не $! вы ж поправите на пид запущенного процесса

Что-то на дефолтном ядре толку от nice -n 19 никакого.

It is by design. Use BFS.

Есть две крайности — (псевдо)реалтайм и вытесняющая многозадачность. Дефолтное ядро стремится к первому, в то время как BFS, BFQ и sched_autogroup тяготеют ко второму.

На самом деле всё с точностью наоборот.

Не годится. Это мне нужно после запуска процесса выяснить его pid и прописать туда. А ведь в фоне периодически запускаются по крону всякие задачи, например Дебиян в воскресенье утром запускает обновление базы xapian с «низким приоритетом» и ещё что-то.

Use BFS.

Мне надоело сидеть на самосборном ядре. Дефолтное ядро часто обновляется, а мне лень каждый раз его пересобирать, в итоге моё сильно отстает от дефолтного, в котором обновления исправляют всякие security issues.

Метки: gentoo

Мне надоело сидеть на самосборном ядре.

ОМГ. Смени дистр тогда.

Если серьёзно, у вас что, оверлея с актуальным ебилдом для BFS нет?

cast megabaks

Это мне нужно после запуска процесса выяснить его pid и прописать туда.

если это причина, по которой не годится, то я даже не знаю, что и сказать.

Как я написал в предыдущем посте, ты можешь использовать cgexec, плюс ты можешь написать свой враппер, который был частично описан в моём посте, на версию получше:

#!/bin/env sh
exec $@ &
echo $! > /sys/fs/cgroup/cpu/lowlevel/tasks

Вот задача, автоматизации создания нужных иерархий это поинтереснее, хотя не сложнее вышеприведённого «скрипта».

У меня Убунта, а метка это чтобы гентушников позвать.

Если серьёзно, у вас что, оверлея с актуальным ебилдом для BFS нет?

Не хочу его вообще использовать. При большом аптайме ядро (PF) у меня пару раз зависало с ним.

Блин, ну вот нафиг так людей запутывать...

Слишком костыльно. Мне проще тогда bfs пользоваться, чем вникать в принцип работы cgroups и писать котыли.

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

как обычно, тред ради потроллить, а в U-A ТС небось вообще винда прописана.

небось вообще винда прописана.

У меня вообще её нет.

тред ради потроллить

Если ты тролишься от одного лишь упоминания генты, это твои проблемы. Ты сам сейчас провоцируешь флейм.

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

если для тебя использование nice 19 program, это нормально, а cgnice 100 program это сложно, то у меня плохие новости.

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

если для тебя использование nice 19 program, это нормально

Да, это нормально и никак иначе. Потому что некоторые дефолтные системные задачи запускаются именно с nice. Это придется тогда переписывать дефолтные скрипты инициализации и всякие конфиги (cron, anacron...), но при обновлении пакетный менеджер будет постоянно спрашивать что делать с изменившимися файлами, поставить новый из пакета или оставить старый.

бред.

+ cp yourscript /usr/local/bin/nice

ну и + не знаю как у вас, а у нас nice вполне успешно работает разруливает на дефолтном шедулере.

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

Я правильно понял, это ограничивает использование процессора, то есть программа просто не сможет нагрузить процессор на 100% (то есть аналогичного работе cpulimit)?

не задумывался, но судя по запуску:

main() {
    for(;;);
}

# cat /sys/fs/cgroup/cpu/lowlevel/cpu.shares 
100

./a.out &
echo $! > /sys/fs/cgroup/cpu/lowlevel/tasks 
cat /sys/fs/cgroup/cpu/lowlevel/tasks

и просмотру htop, одно из ядер нагружалось на 100%, т.е. - может, ядер всего 4 т.е. в случае cpulimit должно было бы быть 50% ядра.

А зачем тебе каждый раз обновлять ядро ? Ты сделай тесты и убедись что на одном и том же железе с одними и теми же задачами новое ядро в лучшем случае не дает никакого прироста производительности, в худшем будет регрессия
Зачем ставить новоe ядро, для цифирки в uname

Какие тесты? Какие циферки? Ядро часто обновляется, т.к. фиксятся баги. Как минимум раз в месяц в среднем.

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

В подавляющем большинстве случаев эти баги никому не вредят

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

но что с новым ядром

Вообще под обновлениями ядра я имел в виду обновления одной ветки, например 3.2.*, вряд ли у таких обновлений есть регрессии.

Естественно, иначе придется сказать «ребята, мы тут всяку хрень втиснули, может будет кому то лучше , может нет, но остальным точно будет хуже» :-)
Не далее как вчера тестировал 2.6.39 (на котором до сих пор сижу) 3.5.4 и 3.6.2
Регрессия везде, во времени запуска прог, в скорости интерфейса по тестам, в скорости архивирования и кодирования. Ну и зачем эти тухлые пряники ?

Во-первых, под псевдореалтаймом я имел ввиду старое определение для пакетной обработки (на ещё советских ЭВМ, например) когда всё честно, каждому и поровну. Во-вторых, дефолтное ядро опирается больше на статусы процессов нежели на события из внешнего мира, т. е. реализует принцип «кто больше работает — тому больше ресурсов», это несколько отличается от Ъ-реалтаймовой многозадачности, где переключение надо здесь и сейчас и моментальную отзывчивость. Если бы ядро к этому тяготело, BFS, BFQ и иже с ними давно бы уже были в ванилле.

Во-первых, под псевдореалтаймом я имел ввиду старое определение для пакетной обработки (на ещё советских ЭВМ, например) когда всё честно, каждому и поровну.

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

А то! На самом деле, когда писал первый пост, просто не помнил, что под реалтаймом понимают сегодня.