LINUX.ORG.RU

2.6.24 и CONFIG_FAIR_GROUP_SCHED


0

0

на заметку.

в ситуации, когда в ядре 2.6.24 включен CONFIG_FAIR_GROUP_SCHED и CONFIG_FAIR_USER_SCHED, в момент когда вы желаете что-то заемержить и посмотреть в это же время фильм, телевизор или послушать музыку, то ничего не выйдет. соль в том что при комбинации CONFIG_FAIR_GROUP_SCHED+CONFIG_FAIR_USER_SCHED время процессора сначала распределяется между пользователями, а потом только между процессорами одного пользователя. причем, root имеет приоритет перед всеми прочими пользователями. к счастью, есть механизм указания пользовательского приоритета. достаточно сделать:

echo 512 > /sys/kernel/uids/0/cpu_share

(умолчание для root-а 2048, для простых смертных: 1024)

★★★★★

Мораль: для сборки должен существовать специальный пользователь. :)

В принципе -- в далекой перспективе -- имевшее место быть и описанное, пойдет во благо, ибо заставить вводить fine-grained privilege control, т.е. потихоньку "расщеплять" права суперпользователя, а отдельным процессам отдавать только часть, необходимую и достаточную для функционирования.

Ну а в краткосрочной перспективе -- не очень хорошо, т.к. прибавит проблем.

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

> Мораль: для сборки должен существовать специальный пользователь. :)

ну да. а еще отдельные пользователи что бы базу locate обновлять, что бы chkrootkit-ы пускать, и прочее и прочее..

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

> fine-grained privilege control

ну так давным-давно же есть -- rsbac: http://www.rsbac.org/why -- именно для того что бы root-а на кусочки порезать. только кому он нафиг сдался..

> Ну а в краткосрочной перспективе -- не очень хорошо, т.к. прибавит проблем.

я бы сказал -- неожиданных проблем.

dmiceman ★★★★★
() автор топика
Ответ на: комментарий от dmiceman

Это самое-то для хостинга. А то, до этого не было ни одного нормального шедулера, который бы это делал. Все или забивали, или писали свои костыли.

Valmont ★★★
()
Ответ на: комментарий от dmiceman

> ну так давным-давно же есть -- rsbac: http://www.rsbac.org/why -- именно для того что бы root-а на кусочки порезать. только кому он нафиг сдался..

Ну, помимо ограничений прав, нужно еще и разделение ресурсов, что теперь мы и имеем :)

annoynimous ★★★★★
()

Огромное Вам спасибо, dmiceman! А я то не сразу понял, из-за какой именно опции у меня load average стал доходить до 7 ;)

BigBiker
()
Ответ на: комментарий от dmiceman

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

Секундочку...

Правильно ли я понимаю, что даже низкоприоритетный (NICE=19) процесс рута будет выполняться предпочтительнее, чем пользовательский с приоритетом по-умолчанию?

annoynimous ★★★★★
()

Но с другой стороны все совсем не плохо, теперь можно, указав малый приоретет для рута, спокойно от пользователя сидеть смотреть фильмы/играццо/слушайть музыку, а он пусть обновляется.

MaDMaN ★★
()
Ответ на: комментарий от annoynimous

> что даже низкоприоритетный (NICE=19) процесс рута будет выполняться предпочтительнее, чем пользовательский с приоритетом по-умолчанию?

да, именно так. во что собственно я и уперся. emerge у меня спокон веков с пониженным приоритетом идет и обычно никому не мешает.

dmiceman ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

Нет, не совсем так, низкоприоритетный процесс рута и нормальный процесс юзера будут делить процессор пополам. При условии, что им выделены одинаковые cpu_share, конечно.

the_one
()

В sysctl.conf это можно как-нибудь запихать?

kaktyc ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.