CFS vs. SD

Которого?

Кто здесь? ;)

Я здесь!

Мож флейм разведем?

Разводите, нам нужен флейм для транклюкаторов, что бы захватить землю.

> Разводите, нам нужен флейм для транклюкаторов, что бы захватить землю.

ух у вас на марсе и трава забористая :)

> сылку с описанием и результатом тестирования в студию. А иначе в рубрику "ученые доказали".

"Я не я и корова не моя". Я со слов Линуса говорю. http://www.ussg.iu.edu/hypermail/linux/kernel/0707.3/2012.html

[ I realize that this comes as a shock to some of the SD people, but I'm told that there was a university group that did some double-blind testing of the different schedulers - old, SD and CFS - and that everybody agreed that both SD and CFS were better than the old, but that there was no significant difference between SD and CFS. You can try asking Thomas Gleixner for more details. ]

[ I realize that this comes as a shock to some of the SD people, but I'm told that there was a university group that did some double-blind testing of the different schedulers - old, SD and CFS - and that everybody agreed that both SD and CFS were better than the old, but that there was no significant difference between SD and CFS. You can try asking Thomas Gleixner for more details. ]

I'm a little bit surprized :)

Меня вот что удивляет: с каких это пор планировщики (стеки TCP/IP, мьютексы, семафоры и прочее, добавить по вкусу :) ) тестируются _медицинскими_ методами?! Они бы еще тестеров на полиграф ака "детектор лжи" посадили! Неужели нет адекватных _численных_ способов иллюстрировать преимущества и недостатки каждого из планировщиков?

И второе (может я пропустил): а где сравнения CFS со _старым_ планировщиком, который пока еще живет в ядре (вопли всяких там гентушников отметем как неорганизованные :) )

> Thomas Gleixner

по немецки том сравнитель :)

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

> Нонсенс. Если кадры показываются с задержкой в 1 секунду, то это ОДИН кадр в секунду, а не миллион.

Нет (с)

Идёт поток "миллион/сек", но с задержкой 1 сек. VoIP никогда не пользовался?

> И второе (может я пропустил): а где сравнения CFS со _старым_ планировщиком, который пока еще живет в ядре (вопли всяких там гентушников отметем как неорганизованные :) )

Ты видел что старое шедуллерное фуфло творит? Кажется, проводили эксперимент не так давно. Три интенсивно жрущих камень процесса запускали на двух камнях, два процесса жрали по 50%, один - 100%. В топку то кривое быдлоподелие. Вот CFS - правильный планировщик, реально делит процессорное время поровну.

>> Нонсенс. Если кадры показываются с задержкой в 1 секунду, то это ОДИН кадр в секунду, а не миллион.

> Нет (с)

> Идёт поток "миллион/сек", но с задержкой 1 сек.

Солидно задвинул. Внушает. (с) Хрюн

И где-ж миллион кадров задерживается по пути? Буферизуются в проводах?

>Три интенсивно жрущих камень процесса запускали на двух камнях, два процесса жрали по 50%, один - 100%. В топку то кривое быдлоподелие. Вот CFS - правильный планировщик, реально делит процессорное время поровну.

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

> И где-ж миллион кадров задерживается по пути? Буферизуются в проводах?

Застревают в шедулере.

У *меня* DC++ в nice работает. Я и в шутеры, впрочем, не играю. Я просто привел пример ситуации, когда на десктопе кому-то может резко понадобиться процессор.

Может, не самый удачный, но довольно реалистичный.

> У *меня* DC++ в nice работает. Я и в шутеры, впрочем, не играю. Я просто привел пример ситуации, когда на десктопе кому-то может резко понадобиться процессор.

В любом случае всё решается приоритетами.

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

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

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

http://www.linux.org.ru/view-message.jsp?msgid=2017062

А вот 2.6.21 патченый нормальным шедуллером CFS на двух камнях(john -test):

13672 anonymous 20 0 3672 1396 944 R 72 0.3 0:24.94 john
13671 anonymous 20 0 3672 1396 944 R 63 0.3 0:26.03 john
13673 anonymous 20 0 3676 1400 944 R 61 0.3 0:24.51 john

И еще(cat /dev/zero > /dev/null):

9491 anonymous 20 0 2692 560 480 R 67 0.1 1:21.67 cat
9494 anonymous 20 0 2696 564 480 R 66 0.1 1:20.51 cat
9492 anonymous 20 0 2692 560 480 R 65 0.1 1:20.23 cat

> У *меня* DC++ в nice работает. Я и в шутеры, впрочем, не играю. Я просто привел пример ситуации, когда на десктопе кому-то может резко понадобиться процессор.

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

> Может, не самый удачный, но довольно реалистичный.

Угу, а то что dc++ - портированная с венды поделка для школьнегоф - это типа побоку?

Для тех, кому не совсем ясно о чем речь поясню: со старым планировщиком при раскидывании трех процессов по двум камням два процесса потребляли по ~50% CPU и один - ~100% (в сумме 200% на 2 CPU), т.е. в два раза больше процессорного времени чем два других РАВНОПРИОРИТЕТНЫХ процесса. Налицо серьезный баг в реализации мультизадачности. Возможно, он затрагивает только HT-конфигурации. С новым планировщиком CFS все три процесса накручивают равное время, поскольку им как равным по статусу(приоритету) выделяется одинаковый ресурс CPU, одинаковое число квантов за интервал времени.

> Угу, а то что dc++ - портированная с венды поделка для школьнегоф - это типа побоку?

Этими отговорками можешь себя лечить. Есть протокол DirectConnect. Исходники открыты. Есть DC-хабы и террабайты инфы, которую можно бесплатно скачать из своего сетевого сегмента(к сведению, внешний трафик стоит 3 рубля за МБ), при чем там не только пераццкие фильмы, варез и порево, но и куча вполне законных дистрибутивов свободного софта, поэтому мне необходим нормальный линуксовый DC++ клиент. В локалке нет ни одного торрента в сегменте, с которого можно было бы лить бесплтатно. Так что умникам-снобам советую пройти в пешее эротическое, потому что достали уже своими идиотскими советами и дебильными отмазками. Запомни, раз LinuxDCPP существует значит это кому-то да надо.

Предлагаю подождать в эксперименте с тремя жрущими CPU процессами и двумя процессорами немного подольше: станет видно что они все-таки "ротируются" (один и тот же процесс работает то один на процессоре, то вместе с другим, переключение ~ 1 раз в 30 сек), и в среднем у них CPU time выравнивается с течением времени.

Я проверял это лично.

> Для тех, кому не совсем ясно о чем речь поясню: со старым планировщиком при раскидывании трех процессов по двум камням два процесса потребляли по ~50% CPU и один - ~100% (в сумме 200% на 2 CPU), т.е. в два раза больше процессорного времени чем два других РАВНОПРИОРИТЕТНЫХ процесса. Налицо серьезный баг в реализации мультизадачности. Возможно, он затрагивает только HT-конфигурации. С новым планировщиком CFS все три процесса накручивают равное время, поскольку им как равным по статусу(приоритету) выделяется одинаковый ресурс CPU, одинаковое число квантов за интервал времени.

Предлагаю подождать в эксперименте с тремя жрущими CPU процессами и двумя процессорами немного подольше: станет видно что они все-таки "ротируются" (один и тот же процесс работает то один на процессоре, то вместе с другим, переключение ~ 1 раз в 30 сек), и в среднем у них CPU time выравнивается с течением времени.

Я проверял это лично.

(сорри, забыл отквотить)

> Предлагаю подождать в эксперименте с тремя жрущими CPU процессами и двумя процессорами немного подольше: станет видно что они все-таки "ротируются" (один и тот же процесс работает то один на процессоре, то вместе с другим, переключение ~ 1 раз в 30 сек), и в среднем у них CPU time выравнивается с течением времени.

Я бы не сказал, что выравнивается. Явно определился один фаворит, который болтается
единолично на одном из процессоров и высасывает из него все ресурсы, перелазя на 50% норму весьма неохотно.

2483 anonymous 25 0 3692 436 376 R 99 0.2 30:29.30 cat
2484 anonymous 25 0 3696 436 376 R 50 0.2 18:05.63 cat
2485 anonymous 25 0 3692 436 376 R 50 0.2 19:19.15 cat

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

Я тоже провел свои тесты на Intel C2D (двухядерник).

Вначале действительно процессы сильно отличались по затраченному времени ЦП. Но вот что можно увидеть спустя полчаса:

R 49.9 0.0 26:21.42 cat
R 25.3 0.0 26:33.48 cat
R 25.1 0.0 30:43.62 cat

Относительная погрешность использования ЦП стала гораздо меньше.

NB Я бы все-таки не стал огульно хаять "старый" планировщик - он был сделан и многократно оттестирован многими людьми. Уверен, что продемонстрированное им поведение известно и является компромиссом между "плохо" и "еще хуже". И не потому, что "руки кривые", а потому что идеального по всем параметрам планровщика не существует. И уверен, что CFS еще юудет иметь проблемы, скажем, на многопроцессорных (N>>10) машинах.

Да, забыл

$ uname -a
Linux node7 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 2007 i686 i686 i386 GNU/Linux

> NB Я бы все-таки не стал огульно хаять "старый" планировщик - он был сделан и многократно оттестирован многими людьми.

Понимаю я это все. Просто вырвалось.

> Вначале действительно процессы сильно отличались по затраченному времени ЦП. Но вот что можно увидеть спустя полчаса:

Ну да, почти вровень... только один процесс получил на 4 минуты больше времени(на 15.2% больше времени чем другие два) по непонятно каким причинам. Ведь никто ему renice -5 не делал? Просто замечательно: система сама выставляет хз какому процессу хз какой приоритет, а юзеру - разбираться что это за чудеса. Ппц. В отличие от этой неадекватной ерундовины, с CFS равноприоритетные процессы почему-то практически сразу идут вровень, что точно согласуется с определением равных приоритетов процессов в мультизадачной среде в отличие brain-damaged логики старого планировщика.

> Уверен, что продемонстрированное им поведение известно и является компромиссом между "плохо" и "еще хуже".

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

> И уверен, что CFS еще юудет иметь проблемы, скажем, на многопроцессорных (N>>10) машинах.

Возможно. Более того я даже уверен, чот новые версии "последней стабильной версии" (c) kernel.org ядра Linux будут обязательно иметь проблемы. А использовать старый дряхлый неадекватный планировщик только потому, что у него крепкая выдержка - это не вариант, у DOS выдержка еще крепче.