3 марта 2010 г. 0:20 пользователь Pavel Labushev <p.labushev@gmail.com> написал:

03.03.2010 02:20, Alex Efros пишет:

> И этот баг можно протестировать достаточно просто: при копировании больших
> файлов (желательно, объёмом на 1GB больше доступной RAM чтобы исключить
> кеширование) чётко наблюдаются два эффекта - крайне низкая скорость и
> высокий iowait (ну и тормозит интерфейс, конечно, но это сложно замерить в
> тестах).

На счёт тормозов интерфейса: не наблюдаю их у себя после того, как после
2.6.30 перешёл на групповое планирование в CFS (не CFQ) между cgroups.
Где связь - не понятно, но она, похоже, есть. С тех пор тормозов
интерфейса не наблюдаю ни при компиляции, ни при emerge-webrsync, ни при
работе transmission (демон, тоже в группе system) - всё это на
сигейтовском 320-тнике, любой ввод-вывод на котором раньше безбожно
тормозил иксы.

Что сделал:

# mount | grep cpu
none on /cgroup/cpu type cgroup (rw,cpu)

В /cgroup/cpu созданы две директории групп: system и user

На старте системы в user/tasks записываются pid'ы Xorg и
дисплей-менеджера, system/tasks - все остальные.

В .bash_profile root'а добавил:
echo $$ > /cgroup/cpu/system/tasks
Чтобы по su -l шелл и его потомки, включая emerge, попадали в группу system.

PS
Кстати, на ядрах с grsec и включённым kernel.grsecurity.chroot_findtask
могут быть аналогичные тормоза при высокой активности процессов в
chroot'ах (при компиляции, например), но это уже связано с блокировками
на планирование внутри ядра во время проверок IPC, а не с глюками i/o. Я
в таких случаях либо отключаю chroot_findtask, либо отказываюсь от
чрутования в пользу RBAC.