Re: Динамически включать-выключать CPU
2011/9/10 Victor Wagner <vitus@wagner.pp.ru>:
> Поэтому вполне сработает такая конструкция
>
> LIST=`cat /dev/cpuset/tasks`
> for pid in $LIST; do
> echo $pid > /dev/cpyset/syscpuset/tasks
> done
Спасибо. Вот как раз того, что шелловский for умеет итерировать по
строке, разделяя newlines, я и не знал.
(Это подойдёт - там просто числа, разделённые newline).
>> Если шеллом можно сделать _это_, может им можно и конфиг разобрать? В
>
> Да, естественно.
>
> Я очень часто делаю конфиги скриптами на том же языке, что и основной
> продукт, и промом просто делаю им source/require и т.д.
Всё что тут надо конфигурировать, по максимуму:
CPUSETNAME=name
CPUS=cpus
MEMS=mems
MOVE_KERNEL_PROCESSES=[true|false]
В первой версии хватит CPUS и MEMS (имя "прибить гвоздиком", имеющиеся
процессы всегда перегонять). Для 80-90% случаев этого IMHO достаточно.
Ну, вообще это _можно_ сделать исполняемым. И вроде бы при ошибке,
если новых строк не добавлять, оно как максимум не сработает, но
система загрузится. Потому что если cpus/mems невалидно, система
просто не позволяет записать задачи в новый cpuset.
> Как мне кажется, куда более прямым решением будет не /sbin/kprint а
> /dev/kprint - маленький такой ядерный модуль, предоставляющий character
> devices, и передающий все, что туда пишется, в буфер сообщений ядра.
Я просто не верю, что готовое решение для логгинга userland процессов
до RW монтирования /var/log отсутствует. Ну сам-то /sbin/init должен
куда-то сообщить об ошибке в /etc/inittab .
> Дело в том, что для /sbin/kprint тебе все равно понадобится какой-то
> интерфейс с ядром - просто так внутреннюю ядерную функцию ты из
> userspace не позовешь.
Вот это и вопрос - позовёшь или нет. Если нет, то для работы решения
требуется собрать ядерный модуль. Значит, чтобы оно работало нормально
при штатном обновлении ядра (подъём версии - тоже штука штатная), мне
ещё и dkms прикручивать придётся. Как-то оно явно того не стоит. Уж
проще этот скрипт выпустить без лога.
(А создавать больше одного cpuset ему не нужно в принципе. Куда более
продвинутая система управления cpuset для sysv init уже есть. А этот
скрипт - для параноидального выгоняния всей системной шушеры _сразу_,
чтобы даже sysv init не дожидаться).
--
Yours, Mikhail Ramendik
Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization
Reply to: