>а вот bfs...
Внизу комментарий самого Коливаса:

Those following the development of the patches for interactivity at massive
load, I have COMPLETELY DROPPED them as they introduce regressions at normal
workloads, and I cannot under any circumstances approve changes to improve
behaviour at ridiculous workloads which affect regular ones. I still see
precisely zero point at optimising for absurd workloads. Proving how many
un-niced jobs you can throw at your kernel compiles is not a measure of one's
prowess. It is just a mindless test.

Интересно, а совместим ли он с Realtime патчем?

>Интересно, а совместим ли он с Realtime патчем?

Нет, несовместим. Последний -rt патч для версии 2.6.33, а сабж для 2.6.35 минимум :)

>Для Ъ. То, что обычно назвают 12309, бывает в двух случаях:

1. Когда систему загнали в своп. И те программы, что из свопа вылазят - тормозят. Это >логично, и это - не баг, иначе просто не может быть.

Признак этого случая: большое число swapin/swapout в выводе команды `vmstat 1` >во время тормозов.

Решение: не забивать память всяким хламом.



2. На многоядерных CPU в кривых дистрибутивах не балансируется обработка IRQ.

Признак этого случая: равномерно растущие счетчики в /proc/interrupts во время >тормозов.

Решение: установка демона irqbalance или ручная балансировка: for f in >/proc/irq/*/smp_affinity; do echo 1 > $f; done

ересь в чистом виде!
акстись, окаянный - 21-ый век - сейчас любая железяка умеет расшаривать irq
а про своп...стену показать?

А насчет того, что тот же эффект, что и от патча можно получить несколькими строками на bash, Леннарт абсолютно прав. И не понятно, чего это вдруг все стали пИсать кипятком от радости.

+1. Адекваты в треде.

>Both videos show the Core i7 970 system running the GNOME desktop

Это улинуса такая тачка? Эх мне бы такое.

Gentoo, последние git-sources + этот патч = под нагрузкой улучшение _кардинальное_

Gentoo, последние git-source и zen-stable. Вместо патча фикс из соседнего треда. Улучшение кардинальное :D

А когда Oracle объявляла об ускорениях в тысячи процентов все почему-то посмеивались над Ларри.

Такими темпами Ораклу скоро и не понадобиться «свой» Linux. Любая Слака подойдет.

>А когда Oracle объявляла об ускорениях в тысячи процентов все почему-то посмеивались над Ларри.

Ускорение в тысячи процентов и улучшение отзывчивости системы - совершенно разные вещи.

> Core i7 970

Видать в Crysis под Wine играет и одновременно ядро компилится.

Если кому нужно deb: Headers и Image deb x86_64

>> Что-ж он не вернулся, когда КДЕ стало тортом?

А кто сказал, что он не вернулся? ;)

В силу того, что КДЕшников в мире осталось исчезающе малое количество(что плохо, так как нужна конкуренция), то остатки просто обязаны были раструбить об этом событии во всём мире, как уже было сделано обнажды.

>остатки просто обязаны были раструбить об этом событии во всём мире,

КДЕшникам пофик, они не ипытывают комплексов по поводу используемого ДЕ, и, соответственно, не пытаются любыми путями обосновать его преимущество перед другими с помошью дебильных аргументов, что-де такой-то уважаемый человек пользуется этаким ДЕ.

как уже было сделано обнажды.

бугога, так то гномеры трубили: «Линус осознал, какие мы крутые! Всем восхищаться полчаса!»

Тем не менее в каждом треде о гноме большая часть от КДЕшников.

>Тем не менее в каждом треде о гноме большая часть от троллей.

fxd

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

Кстати, я правильно понимаю, что mpd будет заикаться под нагрузкой на систему при такой реализации, так как он явно не принадлежит к активному tty?

В силу того, что КДЕшников в мире осталось исчезающе малое количество(что плохо, так как нужна конкуренция)

http://www.linuxjournal.com/content/readers-choice-awards-2010

Ъ:

Best Desktop Environment

Tie: GNOME and KDE

Runner Up: Xfce Third Place: LXDE Fourth Place: Fluxbox

The results from the Best Desktop Environment make more intuitive sense to us (and to this KDE fan) than in the previous two bouts, when GNOME edged out KDE by surprisingly healthy margins. In the 2010 battle royale, KDE jiu-jitsued GNOME and gobbled 7% of its lunch (as well as 3% of Xfce's) to even the desktop score from last year. No other desktop surpassed the 3% mark.

> >Turns out systemd actually does pretty much that

>Выключение systemd делает почти то же самое

Товарищ, вы совсем-совсем не правы, вы вынуждаете меня приложить ладонь к лицу.

Ну ладно, ладно, без театра! :)
Тут я даже по смыслу догадываюсь, что что-то накошмарил, но лингва даёт именно перевод «выключил» или «производить». «Производить систимдэ» не клеилось. Как надо правильно?

Кстати, я правильно понимаю, что mpd будет заикаться под нагрузкой на систему при такой реализации, так как он явно не принадлежит к активному tty?

Нет, не правильно. Активность tty не имеет значения.

>Turns out systemd actually does pretty much that

Кажется, нашёл смысл:

«Сурприз, но систимдэ делает то же самое!». Т.е. в значении «стало неожиданным результатом».

>Turns out
Я всегда перевожу это как «выходит/получается, что»

That said, I do love how the patch looks. I think this is absolutely the right thing to do. My issues are small details. I'd Ack it even in this form (well, as long as spelling is fixed, that really does rub me the wrong way), and the other things are more details that are about how I'm thinking about it rather than «you need to do it this way».

Linus

Gentoo + 2.6.36 + patch = кардинальное улучшение отзывчивости. Большой респект автору патча.

That said, I do love how the patch looks. I think this is absolutely the right thing to do

Как сильно удивятся этому рандомайзеру товарищи, которые уже ручками раскидали всё по cgroups. Эх, не надо всё-таки плодить лишних сущностей, тем более в ядре.

>Конечно нет. Это идея о того, что подобные вещи надо делать в user-space. Ядро предоставляет возможность рулить cgroups, а как и по каким принципам - вопрос не ядра.

ядро все равно рулит группами, просто по дефолту неоптимально. Иначе появлется зависимость ядра от юзерспейса.

В том же треде предлагали интегрировать это управление с оконными менеджерами и прочими КДЕ как более разумное решение для десктопа. Этот патч местами, конечно, помогает, но use-case его достаточно специфичен ввиду привязки к tty.

а кто мешает? Управление оторвали? Грузи свой демон и управляй. А патч позволяетулучшить ситуацию в системах без этого управления .

Потрясающая новость!

>Тем не менее в каждом треде о гноме большая часть от КДЕшников.

От троллей. И это понятно.

Сам по себе факт того, что ты начал мерить количество_КДЕшников–на–гномотред — символизирует. Он как-бы говорит нам: «Гномеры снова комплексуют. Такой же образец попоболи хранится в Палате мер и весов.»

Ты же понимаешь, ни один, даже самый суровый, закаленный в олдскульных нацполах тролль не сможет пройти равнодушным мимо _такого_ количества такой вкусной еды. Вспомни хотя бы «переключалку раскладок в КДЕ». Тему поднимали, в основном, гномеры, и говорили об этом так часто, так много и с таким наслаждением, что невольно складывалось впечатление: переключалка — это единственное, что работает в гноме.

> кардинальное улучшение отзывчивости

Можно по-подробнее?

ядро все равно рулит группами, просто по дефолту неоптимально.

Засунуть всё в одну группу - это называется рулить?

Иначе появлется зависимость ядра от юзерспейса.

Это нормально для юзерспейсовой задачи.

А патч позволяетулучшить ситуацию в системах без этого управления .

Патч, кстати, больше похож на неоптимальное управление, чем то, как ядро «рулит» без него.

Грузи свой демон и управляй.

Так уже. Именно поэтому и говорю, что то же самое в ядре - не нужно.

>Просто пришли смс на короткий номер и получи ссылку на патч для ускорения твоего линукса!!!

Когда Линукс займет 5% десктопов (если займет), то это перестанет быть шуткой.

(с) Trojan_Winlock в анонимном статусе

> Можно по-подробнее?

Системой стало возможно нормально пользоваться при серьёзной нагрузке на IO и CPU. До этого например распаковка сырцов ядра ставила всё раком, теперь просто наблюдается небольшое подтормаживание.

Наложил патч на ядро maverick'а из репов. При stress -c 10 ощутимые улучшения, не заикается вообще. Фурифокс работает отлично. На ядре без патча тормоза видны невооруженным глазом, страницы скролить тяжко.

Гномерам комплексовать незачем. Раскладка работала, работает и работать будет. В отличие от KDE, где она не работала год, как и большая часть софта в KDE. Мой персональный опыт до первого бага в KDE еще ни разу не был дольше 10 минут. Когда любители KDE обратят внимание на откровенную сырость системы, вместо траты времени на восхищение свистелками и перделками - будет лучше всем, и гномерам, и кдеешникам.

>Засунуть всё в одну группу - это называется рулить?

да.

не рулить, это значит заорать в консоль, что группа для процесса не назначена и выпасть в kernel panic.

Это нормально для юзерспейсовой задачи.

нет. в ядре есть дефолтное поведение.

Иначе при отсутствии iptables не было бы сети.

Патч, кстати, больше похож на неоптимальное управление, чем то, как ядро «рулит» без него.

Линус утверждает, что гораздо лучше, чем раньше.

Так уже. Именно поэтому и говорю, что то же самое в ядре - не нужно.

1) неправда. systemd еще не вошел в федору. Значит его нет.

2) дефолтное поведение все равно будет и его тоже можно оптимизировать, главное, не перемудрить.

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

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

> Гномерам комплексовать незачем. Раскладка работала, работает и работать будет.

не знаю, где как, но в Debian Lenny переключение раскладки не работает :)

не рулить, это значит заорать в консоль, что группа для процесса не назначена и выпасть в kernel panic.

Это называется «не работать».

нет. в ядре есть дефолтное поведение.

Дефолтное поведение для cgroups - свалить всё в одну группу, пусть пользователь сам разбирается, что ему надо.

Иначе при отсутствии iptables не было бы сети.

Совсем не корректное сравнение, имхо.

Линус утверждает, что гораздо лучше, чем раньше.

Зато другие говорят, что не хотят ради улучшения интерактивности в редких случаях (как у Линуса, например) ухудшать остальную производительность.

1) неправда. systemd еще не вошел в федору. Значит его нет.

Плевать на него. Он не нужен. А раскидать процессы по группам можно и без него.

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

Административный ресурс, имеющийся у Линуса, позволяет пренебрегать многими вещами...

Но не сейчас, когда задача решена только в голове одного Ленарта.

Даже тут отписывались про «патч», который «работает на любом ядре». Хоть и топорное решение, но показывает, что в юзерспейсе это решать можно и нужно.

Емнип, в том же lkml подобный спор свёлся к тому, что у юзеров чаще обновляется - ведро или юзерлэнд.

>Гномерам комплексовать незачем.

Твоя реакция — пять шаблонных слов о гноме и словесный понос про кеды — говорит об обратном. Лютый, злой батхерт. Иначе, с чего бы тебе за КДЕшников так переживать?

Потерю производительности ещё показать надо. ЧТо-то я никаких жалоб не видел на это, так что если оно и есть - то не заметное и не приводящее к проблемам. А для нежелающих «ради улучшения интерактивности в редких случаях (как у Линуса, например) ухудшать остальную производительность» есть sysctl и конфиг ядра.

Потерю производительности ещё показать надо. ЧТо-то я никаких жалоб не видел на это, так что если оно и есть - то не заметное и не приводящее к проблемам.

Ну я улучшений никаких не заметил. use-case разный.

А для нежелающих «ради улучшения интерактивности в редких случаях (как у Линуса, например) ухудшать остальную производительность» есть sysctl и конфиг ядра.

Это был какой-то известный товарищ в lkml. Выражался в том смылсе, что крайне против включения этого дела.

А может «sysctl и конфиг ядра» оставить любителя конпелять в 64 потока на семпроне?

а теперь интересное.

Gentoo ~amd64, 2.6.36-zen1 (BFQ, BFS, без патча и cgroups)
все это крутится на i7-840QM + 8 гигов оперы.

Сделал alias make=«nice -19 make», как сказал CK.

Параллельно идет сборка ядра с make -j64 -s, полноэкранный флеш, flac в audacious, и в бэкграунде играет 1080p rip. Ничего не тормозит.

таже фигня. Своё ядро с ck и bfq. Ничего не заикается. Сча пишу с ядра с патчем croups и не вижу никаких улучшений. :) Может быть оно есть, если с ванильным ядром сравнивать - фиг знает.

>Это называется «не работать».

ну в итоге да. вот не укажешь ядру, где root или кто там init и все, не рабтает.

Дефолтное поведение для cgroups - свалить всё в одну группу, пусть пользователь сам разбирается, что ему надо.

это один вариант дефолтного поведения. Был предложен другой, субъективно более подходящий для дефолта.

Совсем не корректное сравнение, имхо.

жа нет. все корректно. Ядро не должно зависеть от юзерспейса. Из юзерспейса можно подкручивать параметры, но это не отменяет разумного дефолта.

Зато другие говорят, что не хотят ради улучшения интерактивности в редких случаях (как у Линуса, например) ухудшать остальную производительность.

да ведь патч не меняет производительность, он меняет _дефолтные_ приоритеты процессов и только.

Плевать на него. Он не нужен. А раскидать процессы по группам можно и без него.

ну так напишите свое решение,.

Другими словами, выбирайте между решениями, а не между решением и чем-то несуществующим, но словесно описанным, как «можно раскидать процессы по группам»

Административный ресурс, имеющийся у Линуса, позволяет пренебрегать многими вещами...

да ведь никакой ресурс не позволит линусу выбрать несуществующее решение, к тому же за пределами зоны ответственности.

Даже тут отписывались про «патч», который «работает на любом ядре». Хоть и топорное решение, но показывает, что в юзерспейсе это решать можно и нужно.

И про него сошлись на том, что это не решение. «Это идея о того, что подобные вещи надо делать в user-space.» сказал сам автор вброса.

Но Линус не может выбирать между решением и идеей. Выбирать можно только между решениями.

Емнип, в том же lkml подобный спор свёлся к тому, что у юзеров чаще обновляется - ведро или юзерлэнд.

Что лишний раз подтверждает, что вопрос яйца выеденого не стоит.

а в 2.6.27 ядре 12309 есть?

Конечно. У тех, у кого оно есть (или было) - оно есть на всех, начиная с 2.6.18 ЕМНИП.

это один вариант дефолтного поведения. Был предложен другой, субъективно более подходящий для дефолта.

Субъективно, текущий подходит лучше именно как дефолт. В силу простоты, очевидности и предстказуемости.

Ядро не должно зависеть от юзерспейса.

Оно и не зависит. Откуда вообще эта мысль появилась?

Из юзерспейса можно подкручивать параметры, но это не отменяет разумного дефолта.

При наличии возможности подкрутить, разумный дефолт должен быть максимально простым и надёжным. Всё остальное крутится.

да ведь патч не меняет производительность, он меняет _дефолтные_ приоритеты процессов и только.

Отсюда напрямую следует, что приоритет процесса не влияет на производительность. По-моему, это не совсем так.

ну так напишите свое решение,.

Да, это довольно интересно. Скелет уже работает.

Другими словами, выбирайте между решениями, а не между решением и чем-то несуществующим, но словесно описанным, как «можно раскидать процессы по группам»

Для «раскидать по группам» никаких решений не надо - всё давно есть и давно работает. Просто не кто не озаботился тем, чтобы взять и раскидать. Делается это элементарно. И патчи для этого не нужны. Давай ещё все варианты раскидывания захаркодим в ядро!

да ведь никакой ресурс не позволит линусу выбрать несуществующее решение, к тому же за пределами зоны ответственности.

Зато он позволяет ему делать как ему нравится, а не как лучше. Этого достаточно.

И про него сошлись на том, что это не решение. «Это идея о того, что подобные вещи надо делать в user-space.» сказал сам автор вброса.

И? Этот подход работает, что не так? 5 строк на баше надо запихивать в ядро только потому, что их никто не удосужился по дефолту в дистр впихнуть?

Но Линус не может выбирать между решением и идеей.

Патч войдёт только в 38-е ядро. Сделать из идеи решение можно гораздо быстрее. Если кому-то будет надо. Или в ядре должно быть всё, что ещё не успели написать в user-space?

Что лишний раз подтверждает, что вопрос яйца выеденого не стоит.

Что показывает отсутствие преимуществ у патча перед user-space решением.

Проверь тест с dd - у меня таки все подвисает.

> alias make=«nice -19 make», как сказал CK.
а подумать? ;)
PORTAGE_NICENESS =19

это ты типа предлагаешь вручную постоянно раскидывать процессы по группам? думаешь, всем настолько делать нехер?