LINUX.ORG.RU
Форум — Talks  

Очередной 12309-капец. Теперь и без патча и на любых вёдрах.


0

7

http://www.opennet.ru/tips/2478_cgroup_latency_kernel.shtm
Вроде не баян. Или в толксах уже обсудили/на главной в комментах было? ))
Сам не проверял, УМВР (тьфу-тьфу-тьфу) и без того, на разных машинах с разным количеством процов.

Для Ъ:

По заявлению одного из разработчиков из компании Red Hat добиться эффекта
существенного повышения отзывчивости десктоп-систем в условиях большой фоновой
нагрузки можно через использование cgroup без дополнительных патчей Linux-ядра
(http://www.opennet.ru/opennews/art.shtml?num=28671). Более того
утверждается что cgroup-метод работает
даже лучше патча с привязкой групп планирования к TTY.

Метод проверен на Linux-ядре 2.6.32.

В /etc/rc.local добавляем:

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user


В ~/.bashrc:

if [ «$PS1» ] ; then
mkdir -m 0700 /dev/cgroup/cpu/user/$$
echo $$ > /dev/cgroup/cpu/user/$$/tasks
fi

★★

 ← 1 2 →

эх...ща ребутнусь в ядро с bfs+bfq without autogroup...

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

> Было в обсуждении патча на 7-8 странице...
Блин... Ну думаю я не один такой, кто не добрался до 7-й страницы, все равно может кому пригодится.

Tayler ★★
() автор топика

Я так понял, перезагрузка системы в этом случае не требуется, а достаточно перезайти в DE?

firestarter ★★★☆
()

о, отлично! завтра проверю, сейчас лень уже.

isden ★★★★★
()

Более того утверждается что cgroup-метод работает даже лучше патча с привязкой групп планирования к TTY.

Метод один и тот же - разделение процессов на группы. Просто в данном случае это делается почти вручную, а тот патч всё автоматизирует.

Кстати, cgroups в ядре уже давно, и все кому надо этим пользовались.

Deleted
()

Ни патч, ни этот костыль каких-либо значимых изменений на моей машине что-то не принесли. Все равно есть фризы и тормоза при интенсивных фоновых задачах (компилляция, dd).

Alsvartr ★★★★★
()

не знаю, имеет ли на 2.6.26 12309 место, но сейчас запущены dd, перекодирование ape2flac, gzip. Тормозов не замечено.

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

Ты настолько Ъ, что даже темы не читаешь?

Это фикс без патча.

devl547 ★★★★★
()

Попробовал (ядро 2.6.35, Arch).
На глаз вроде как отзывчивость (скорость работы с окнами, например) стала лучше.

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

>Ни патч, ни этот костыль каких-либо значимых изменений на моей машине что-то не принесли. Все равно есть фризы и тормоза при интенсивных фоновых задачах (компилляция, dd).

Рождённый ходить летать не сможет. Это про твоё железо.

Absolute_Unix ★
()

Реально работает!

Deleted
()

Если такая возможность была давно , то куда смотрели разработчики дистров десктопных ее не включая ?? Я в полном непонимании

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

> и все кто об этом знал :)

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

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

Рождённый ходить летать не сможет. Это про твоё железо.


Да что ты говоришь. Расскажи мне больше.

Alsvartr ★★★★★
()
Ответ на: комментарий от ls-h

>А можно объяснение как оно работает?
Особенно интересно как оно влияет на процессы, которые запускаются не из баша

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

> Особенно интересно как оно влияет на процессы, которые запускаются не из баша

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

annoynimous ★★★★★
() 
roman@linux:~$ sudo -s
[sudo] password for roman: 
mkdir: невозможно создать каталог `/dev/cgroup/cpu/user/16314': Нет такого файла или каталога
bash: /dev/cgroup/cpu/user/16314/tasks: Нет такого файла или каталога
root@linux:~# mkdir -p /dev/cgroup/cpu
root@linux:~# mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mount: специальное устройство cgroup не существует
root@linux:~# mkdir -m 0777 /dev/cgroup/cpu/user
root@linux:~# mkdir -m 0777 /dev/cgroup/cpu/user
roman77 ★★★★★
()
Ответ на: комментарий от annoynimous

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

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

Потому что в группах у меня висят все процессы, а отзывчивость все-равно отличная стала.

~$ find /dev/cgroup/cpu/user/ -name tasks | xargs cat | xargs ps
  PID TTY      STAT   TIME COMMAND
 5522 pts/1    Ss     0:02 bash
 6407 pts/1    S+     0:00 xargs ps
21183 tty1     S      0:01 -bash
21276 tty1     S+     0:00 /bin/sh /usr/bin/startx
21293 tty1     S+     0:00 xinit /home/bobrov/.xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.wLcrrotC7l
21294 tty8     S<s+   1:33 /usr/bin/X -nolisten tcp
21298 tty1     S      0:00 ck-launch-session /usr/bin/awesome
21301 tty1     S      0:12 urxvtd -q -f -o
21307 tty1     S      0:01 xwrits +breakclock +lock +mouse
21317 tty1     S      1:52 /usr/bin/awesome
21321 tty1     S      0:00 dbus-launch --autolaunch 882b698daf592883ec237f054b078551 --binary-syntax --close-stderr
21322 ?        Ss     0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
21339 pts/0    Ss+    0:01 bash
21465 tty1     Sl     2:17 /usr/lib/chromium/chromium
21472 tty1     S      0:09 /usr/lib/chromium/chromium
21474 tty1     S      0:00 /usr/lib/chromium/chromium --type=zygote
21499 tty1     Sl     0:04 /usr/lib/chromium/chromium --type=extension --lang=en-US --force-fieldtest=ConnCountImpact/conn_cou
21504 tty1     Sl     0:03 /usr/lib/chromium/chromium --type=extension --lang=en-US --force-fieldtest=ConnCountImpact/conn_cou
21543 tty1     Sl     1:31 /usr/lib/chromium/chromium --type=renderer --lang=en-US --force-fieldtest=CacheSize/CacheSizeGroup_
25597 pts/3    Ss+    0:08 ncmpcpp
31322 pts/5    Ss     0:02 bash
31379 pts/5    S+     0:04 /usr/bin/python /usr/bin/snaked -s snaked
baverman ★★★
()

Мой 12309-капец настал с установкой NetBSD.

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

Вы заколебали! Этот костыль лечит планировщик задач, а 12309 возникает из-за кривого планировщика ввода-вывода.

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

То есть, даже если бы был, не помогло бы

Hokum ☆☆☆☆
()
Ответ на: Aaaaaaaa от Mobyshvein

Ре: Aaaaaaaa

> Да вам што, религия запрещает главную страницу или ленту новостей просматривать?!
Т.е. все должны были на восьмой странице комментариев к новости прочитать упоминания этого способа, затем порыться в РедХатовской рассылке и найти эти скрипты?) Или вы тоже не прочитали тему (хотя бы название внимательно)?

Tayler ★★
() автор топика

блин, я не могу понять..

почти никогда из консоли ничего не запускаю, мне этот способ поможет хоть чем-то хотя бы теоретически?

(тормоза регулярные)

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

при чтении/копировании не тормоза.. при чтении/копировании жопа.. а при 100% подтормаживает всё.. прокрутка в браузере в частности..

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

Я сабжевый скрипт не пробовал, но если он делает то же, что и патч, то отзывчивость должна возрасти, при загрузке проца

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

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

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

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

xorik ★★★★★
()

Епт. 12309 - это комплекс багов в ядре и железе, их нельзя исправить, поместив приложения в контейнеры.

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

> При компиляции в хрен знает сколько потоков, на атоме можно спокойно работать.

А при чем здесь компиляция и 12309?

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

Причем здесь 12309 я тоже не знаю, скорее всего для красного словца, ведь ОП скрипт — аналог волшебного патча. И как решение для пиления cpu-bound нагрузки прекрасно подходит.

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

И да. На моих железках, 12309 последний раз был на 31-ом ядре, после этого как бабка пошептала.

baverman ★★★
()

Сенкс

Вчера увидел, только добрался добрался домой. Метод работает. Не слушай про бояны. Спасибо. Потому много лет ЛОР и читаю. Ещё надо почитать про procps-cgroup - Utilities for monitoring your system and processes on your system with cgroup support.

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

>а 12309 возникает из-за кривого планировщика ввода-вывода.
ололо
т.е. по-твоему все планировщики кривые?
т.е anticipatory, deadline, cfq, bfq, ncq ну и наконец отсутствие планирования как такового - noop.
сурово чо

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

Если кривой шедулер io вызывает тормоза других процессов,
то это проблема _шедулера задач_.

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

>отсутствие планирования как такового

Там есть request merging вроде.
У меня, кстати, с noop скорость dd выше, но виснет все сразу и серьезно.

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

>А ты считаешь что 12309 это фича линукса? :)
аха - это кривое ядро
где именно хз - было бы известно - давно бы исправили
а вот к планировщикам ввода-вывода 12309 не имеет никакого отношения

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

у меня харды с ncq.. и все равно такая вот фигня.

Вот уже час сижу и io шедулеры мучаю настройками - какие-то более честные, какие-то более быстрые.. Но вот висит на dd все одинаково.

//Вот блин, сделали бы пингвина более модульным - в разы все проще было..

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