Ох лол, держите меня трое)))

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

зы не копируйте видео, не нарушайте копирастические законы

RedPossum (02.01.2010 3:56:58)

BFS

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

troop> Если посмотреть более старые тесты, то можно увидеть, что отставание CFS там гораздо сильнее. В .32 оставание уже гораздо меньше. Есть основания пологать, что в .33, ситуация еще лучше для CFS

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

Quasar (02.01.2010 23:00:11)

r0mik> кодирование можно реализовать CUDA

А за такое руки отрывать надо.

Quasar (02.01.2010 23:16:02)

Led> Что ты этим хотел сказать?

Очевидно, он хотел сказать то, что сам Инго Молнар признал CFS defective by design

Quasar (02.01.2010 23:22:18)

ttnl2> Ещё надо учесть, что BFS плохо работает с NUMA и заточен под нужды десктопа. Поэтому CFS выкинуть не удасться.

И не надо выкидывать. Надо лишь принять BFS и дать возможность выбора.

Quasar (02.01.2010 23:23:11)

>Очевидно, он хотел сказать то, что сам Инго Молнар признал CFS defective by design

Для своих задач CFS очень даже не плох, для компов где количество ядер от 8 и более. На меньшем количестве ядер алгоритм CFS вносит излишний оверхед. BFS лишён оверхеда, но и масшатируемость много меньше.

Robotron (03.01.2010 1:14:30)

>бесполезный быдлокодеришко Инго Молнар...,
>который нифига полезного в своей жизни не сделал

Я так понял, что это шутка.

>Надо лишь принять BFS и дать возможность выбора.

Беглый взгляд на код BFS дает понять, что его код сырой, далек
от стабильности и написан на скорую руку:

struct rq {
#ifdef CONFIG_SMP
#ifdef CONFIG_NO_HZ
unsigned char in_nohz_recently;
#endif
#endif

(там еще много таких приколов).

Если Линус и товарищи, учитывая степень адекватности Кона Коливаса,
решат, что им не в падлу поддерживать сразу два планировщика, то будет
вам два планировщика в ядре.

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

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

Кстати, кто не в курсе, Коливас тоже участвовал в разработке CFS..

ttnl (03.01.2010 5:15:46)

Robotron> Для своих задач CFS очень даже не плох

Вот именно. Для своих. А Инго Молнар утверждает, что для _всех_ задач он лучший.

Quasar (03.01.2010 13:16:33)

Если CFS затачивать под десктоп, на серверах он будет хуже. Так что лучше иметь несколько планировщиков.

Quasar (03.01.2010 13:17:50)

Затачивают обычно добавлением ifdef'ов, которые определяются при конфигурации. Так что ничто не ухудшится. Интересен другой случай. Была бы возможность вообще отключить эти области планирования. Зачем они на двухядерном десктопе?! Все эти функции по нахождению самых простаивающих групп и т.д. Но такой возможности ни в одном планировщике нет.

ttnl (03.01.2010 15:08:00)

>Затачивают обычно добавлением ifdef'ов, которые определяются при конфигурации.

Не только. Есть ещё /proc/sys/kernel/sched_*

>Была бы возможность вообще отключить эти области планирования. Зачем они на двухядерном десктопе?!

/proc/sys/kernel/sched_features - недостаточно для "отключения областей планирования"?

Led (05.01.2010 15:08:54)

ЕМНИП Коливас когда-ты пытался пропихнуть код для динамического выбора шедулера для процессов (не для IO). Почему его не приняли - хз

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