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

Было в обсуждении патча на 7-8 странице...

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

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

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

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

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

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

> и все кому надо этим пользовались.

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

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

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

Сделайте кто-нибудь голосовалку по сбору АнсамБля Баянистов.

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

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

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

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

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

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

Aaaaaaaa

Да вам што, религия запрещает главную страницу или ленту новостей просматривать?!

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

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

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

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

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

А можно объяснение как оно работает?

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

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

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

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

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

~$ 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

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

А у меня больше нет компутера, где был 12309. Мне поможет этот воркэраунд?

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

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

Ре: Aaaaaaaa

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

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

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

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

Тормоза при чтении/копировании или тормоза при 100% загрузке проца?

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

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

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

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

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

Плацебо? (:

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

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

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

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

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

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

Сенкс

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

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

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

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

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

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

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

дык noop ничего не планирует - поэтому без ncq проседает на многопоточности

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

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

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

дык скока раз повторять?
12309 не имеет отношения к планировщикам i/o