Результаты тестирования планировщика задач BFS

Охренеть разницы... 65%, 30%. Мда.... надо их скрестить ))

>phoronix.com
Почему метки "британские ученые" не стоит?

Проверено: Shaman007 (*) 15.09.2009 10:17:11

>Почему метки "британские ученые" не стоит?

+1

вчера ещё на форониксе этот чудо-тест видел.
они скедулер, ориентированный на отзывчивость, проверяют компиляцией и всякой синтетикой.
или я чего-то не понимаю?

> в особенности на задачах компиляции

лучше вообще использовать SCHED_BATCH :)

Коливас же писал, что сложно реализовать синтетические тесты для проверки отзывчивости. А фороникс как всегда в своём духе - тестят как попало:)

еще бы такой бы тест с bfq бы :) и всё вместе..

Г*, а не тестирование!

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

>еще бы такой бы тест с bfq бы :)
поищи

Херня этот ваш BFS, никак их чудес от него я не увидел.Могут что угодно в своих тестах писать, своё веское я уже составил.

Собрал себе ядро с BFS. Тестов приборами не проводил, однако есть некоторые конкретные результаты.

Итак, тестовая машина - MacBook первой серии: Intel Core Duo T1500 (2 GHz), 2Gb RAM DDR2-667, хард SAMSUNG HM500LI (500Gb, SATA, 2.5"), видео Intel GMA950, чипсет i945.

Ядро 2.6.31, PREEMPT=n, 300Hz, tickless. Cpufreq: ondemand.

Тест первый: 1) загружаемся в KDE 4.3.1 с включенным композитингом (настройки эффектов из коробки). 2) Открываем dolphin, маунтим им раздел с фильмами. 3) запускаем играться два фильма (720p, mkv) через mplayer (вывод через Xv). 4) открываем konsole на полный экран и включаем там htop. 5) пытаемся смотреть какой-нибудь фильм.

CFS: смотреть невозможно, тормозит и дергается. BFS: оба фильма идут гладко. Если добавить дополнительную нагрузку в виде компиляции в один поток, то таки начинаются периодически заметные тормоза при просмотре.

Тест второй: тот же KDE 4.3.1 с композитингом по умолчанию, открываем konsole на весь экран, запускаем компиляцию make -j2, а рядом - в опере открываем youtube и делаем флэш на полный экран

CFS: безбожно дергается BFS: ни намека на тормоза

Третий тест несколько огорчил результатами: один фильм, компиляция на фоне в два потока таки вызывает тормоза на BFS, поэтому на CFS пробовать не стал.

Делайте выводы. По мне - очень хорошо, а если можно еще больше - так вообще замечательно. Глюков пока никаких не заметил.

>В 2 тестах (World of Padman, сборка PHP) производительность BFS и CFS была на одном уровне.

Судя по 59фпс, они vsync забыли отключить.

А почему со стандартным планировщиком никто ничего не сравнивает?

>>В 2 тестах (World of Padman, сборка PHP) производительность BFS и CFS была на одном уровне.

>Судя по 59фпс, они vsync забыли отключить.

xD

Потому что коливасный холивар связан именно с CFS, как планировщиком появившимся в результате неприятия патчей коливаса:)

нда, шедулер ориентированный на пользовательскую систему, значительно лучше при обработке http запросов в apache, типично пользовательское использование, да

>Херня этот ваш BFS, никак их чудес от него я не увидел.Могут что угодно в своих тестах писать, своё веское я уже составил.

Для тебя что BFS что CFS всё херня т.к. проц у тебя одноядерный и тебе без разницы какой из них использовать.

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

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

Мда, тестирование, конечно стрёмное. Хотя по большому счёту оно тоже имеет смысл - не вызовет ли улучшение производительности десктоп-окружения провала в работе апача? Как минимум - академический интерес, как максимум - разделить, например: на сервер я поставлю cfs, а на десктопе у меня ничего такого нет - я bfs вкачу.

А безотностительно "тестов",судя по отзывам, bfs - вкусняшка. Прямо интересно.

Кстати, судя я по http://thread.gmane.org/gmane.linux.kernel/886319, CFS уже подкрутили, и можно ожидать улучшение отзывчивости в следующей версии ядра.

>Ядро 2.6.31, PREEMPT=n, 300Hz, tickless. Cpufreq: ondemand.

На хабре читал обратное: tickless=n, 1000Hz для bfs. Где правда?

>На хабре читал обратное: tickless=n, 1000Hz для bfs. Где правда?

tickless = off обязательно, 300 hz или 1000 hz это уже в зависимости от слабости компа, чем слабее тем выше, у меня BFS/300 hz всё летает

Фороникс -- это диагноз.

по поводу компиляции - у них бредовое сравнение т.к. количество jobserver'ов автоматически у них выставляется на количество ядер*2 в то время как коливас однозначно рекоммендует использовать по количеству ядер т.к. именно в этом случае получается наибольший прирост производительности

>нда, шедулер ориентированный на пользовательскую систему, значительно лучше при обработке http запросов в apache, типично пользовательское использование, да

Это следствие того, что он лучше справляется с большим количеством процессов, а это типичная ситуация для десктопного окружения.

Мда, кислые тесты. Там только один тест на мультипотоковость - "Static Web Page Serving". Все остальное процессы с одним потоком по сути. Да они еще забыли запустить и потестить Java, вот там была бы такая же разница в 65%.

> А почему со стандартным планировщиком никто ничего не сравнивает?

Что за стандартный планировщик?

> Для тебя что BFS что CFS всё херня т.к. проц у тебя одноядерный и тебе без разницы какой из них использовать.

Тссс... Спугнешь эксперта!

>А почему со стандартным планировщиком никто ничего не сравнивает?

CFS и есть стандартный планировщик на данный момент.

// К.О.

>На хабре читал обратное: tickless=n, 1000Hz для bfs. Где правда?

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

>отзывчивости это положительно не скажется

в реальности всё с точностью до наоборот.

(Threaded I/O Tester) быстрее на 46%, как нетрудно посчитать.

Но НАШИ эксперты на глаз чувствуют превосходство BFS :)

http://groups.google.ru/group/linux.kernel/browse_thread/thread/33d56fb57f11e238
вот ещё за засыпку.

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

>>отзывчивости это положительно не скажется

>в реальности всё с точностью до наоборот.

Сам же перед этим говил:

>tickless = off обязательно,

>А так у меня в cfs всё отлично... ив идео сколько угодно одновременно играют и ничего не томрозит... >Так, что даже и не знаю.

"С таким счастьем и на свободе?!" О. Бендер (Золотой телёнок)

>Сам же перед этим говил: >>tickless = off обязательно,

Ты пишешь, что dynamics tickless чтобы НЕ генерировать лишний раз прерывания таймера, это работает именно при = ON (!!!!!!!!). Я пишу что нужно ставить OFF чтобы всегда генерировать прерывания.

> CFS: смотреть невозможно, тормозит и дергается. BFS: оба фильма идут гладко.

Если не в падлу, попробуйте сравнить ещё раз CFS и CFS с io-шедуллером anticipatory. Понимаю, что звучит бредово, но когда-то аналогичное безобразие вылечило именно замена io-шедуллера. Хочется знать, эффект по прежнему в силе? Просто проверять имеет смысл на одном железе и если вы уже сравнивали CFS и BFS...

>Ты пишешь, что dynamics tickless чтобы НЕ генерировать лишний раз прерывания таймера,
>Я пишу что нужно ставить OFF чтобы всегда генерировать прерывания.

Ы?

>Ы?

перечитай ещё раз своё предложение:

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

Это скажется отрицательно на отзывчивости. Разницу в русском языке между _не скажется положительно_ и _скажется строго отрицательно_ объяснять?

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

Не, не дятлы, они мышой елозили по экрану во время компиляции. :D

спасибо за такой отчет... теперь точно попробую bfs

>перечитай ещё раз своё предложение:

Я сказал, что tickless должно быть выключено, потому что:

>>На отзывчивости это положительно не скажется,

Что тут непонятного?

>Это скажется отрицательно на отзывчивости. Разницу в русском языке между _не скажется положительно_ и _скажется строго отрицательно_ объяснять?

Начинай.

>Я сказал, что tickless должно быть выключено, потому что: >>На отзывчивости это положительно не скажется,

это ложь, ты сказал:

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

экономить энергию dynamic ticks позволяет во включённом(!) состоянии таким образом из контекста предложения следует, что ты тут говоришь о ticks = ON. Если ты хотел сказать ровно наоборот то либо ты не владеешь русским языком либо понятия не имеешь о том, как работает dynamic ticks.

Если производительность реально на 30% выше при тестах на апаче, то серьезным конторкам вместо 10000 компов, надо будет 7000 купить, и соответственно мощностей электрических меньше, кондиционирования площадей и прочего... А на производительность вашего десктопа по большому счету все далеко...

> на апаче, то серьезным конторкам

У серьезных конторок затык не в апаче, а в oracle, postgres или mysql с большин количеством коннектов и тяжелым threaded I/O. Намек ясен? :-)

> А на производительность вашего десктопа по большому счету все далеко

А как же тогда ОН? Про это анестезиолог и говорил неоднократно - делают поддержку 1024 процессоров и 1000 дисков, а на обычных юзеров задвинули. Если продолжать в том же духе, то ОН не наступит никогда!

Мы, сообщество анонимных аналитиков, этого допустить не можем. Надо выступить с петицией, требующей включения в ядро нескольких шедулеров (по образу и подобию I/O шедулеров).

Проверял на своей генте - все как ты говоришь, но!

Есть основная проблема: emerge что-нибудь ... зависает намертво.

>экономить энергию dynamic ticks позволяет во включённом(!) состоянии

А нет, млять, обычно стараются экономить работу цпу на выключенных компах.

>таким образом из контекста предложения следует, что ты тут говоришь о ticks = ON.

Из этого вообще ничего вразумительного не следует, тем более что-то из моих слов.

>Если ты хотел сказать ровно наоборот то либо ты не владеешь русским языком либо понятия не имеешь о том, как работает dynamic ticks.

А вот и нет, это все относится к тебе.