здорово! ;)) жалко этого в 2.4 уже не будет.. надо будет попозже потестить 2.5.х начиная с 7 или 8 го.

Why not ? Take this patch, and test it just now ;)

for 2.4.17:

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-A0.patch

Хммм это SMP and UP scheduler даж не знаю есть толк для одного процессора от этого патча?

anonymous (*) (2002-01-04 11:32:17.0)

UP это UniProcessor (один процессор)

Толк есть... Молодец Инго, да и работа основательно сделана... Теперь и у Майкрософта, после опубликования данной работы, появятся "... улучшения планировщика задач..."...:)

Всех благ!

Хм, как работает - пока не успел попробовать, в процессе сборки... Но вот при сборке ругнулся на loop.c, типа structure has not member named nice Пришлось пока loop убрать...

А кто-то пробовал?

Пару вопросов:
1. Мужики, а кто-то пробовал с ядром 2.4.17 ???
1.1. Работает?
1.2. А глюки?
2. Есть ли реальное увеличение производительности, и если да, то на какиз задачах?!

Заранее спасибо!!!

Маленькое замечание: Когда производительность линейно _растёт_ при увеличении n, тогда уместно говорить о алгоритме со временем исполнения O(1/n), а не О(n). Производительность планировщика всё-таки _падает_, а не растёт, как об этом ошибочно написал оригинальный постер. Мы в материальном мире живём :)

А так - молодец Molnar!

хммм я попробую
только какие тесты придумать чтоб простенько и со вкусом и из того что есть?
И еще вот такой url http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-A0.patch
вообще может быть или это все таки ошибка?
ни мозилла ни wget такой урл не принимают. впрочем я все равно скачал но интересно.

Мы тут, вообще-то рассуждаем о алгоритме планировщика со временем выполнения O(1), имея в виду что время выполнения никак не зависит от числа процессов в RUNNABLE состоянии.

И производительность планировщика не падает при увеличении числа процессоров, потому что теперь планировщик может одновременно работать сразу на всех процессорах. Что и демонстрируют цифры бенчмарков в оригинальном письме.

2green: я так понял, что чудеса новый планировщик показывает на большом количестве процессов, и для сервера это есть очень хорошо. Но до конца не разобрался... Что планировщик делает если, скажем, три процесса с одинаковым приоритетом на двух процессорном SMP?

Матюкается если компилить с reiserfs. Смотрит сколько было переключений контекста по старому :)) Ну и в loop.c вместо __nice ищет nice

Вышел новый патч:

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.2-A1.patch
http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-A1.patch

wget умеет такое тянуть, если кавычки не забыть.

2green: Обсуждаем мы с тобой одно и то же, и даже теми же терминами. Я всего лишь указал на неверную фразу по поводу "практически линейного роста производительности планировщика с ростом количества процессоров".

Производительность планировщика не может _расти_ с числом процессов. Она _падает_, то есть время, потраченное в планировщике, увеличивается в соответствии заявленной асимптотичностью алгоритма O(n), O(1) демонстрируют только некоторые подсистемы планировщика.

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

Ноывй планировщик работает в любом случае не хуеж чем старый. Но особенные чудеса, конечно на много-way SMP и/или на длинных run queues.

А делает он то что и положено. Запустит из них два (базируясь на предыдущей информации о их работе). Потом, когда один процессор освободится (потому что у дного из процессов кончится тайм-слайс или потому-что один из процессов отдаст сам (или не сам) управление) запустится третий.

А интересно, этот новый шедулер заменит старый в 2.5.X или будет выходить в виде патчиков как ac к примеру?

Господа, а кому-нить удалось пропатчить 2.5.2-pre6 этими патчами "без напильника"? Там, оказывается. в самом низу страницы с патчами есть ма-а-а-ленькая ссылка на полуметровый diff еще одного разработчика. И даже с этим diff'ом патч не применяется, спотыкаясь на ... sched.h!

Сыровато как-то все это. Поторопились они....

Пиши автору, в чем проблема то?
Ни с первым ни со вторым патчем у меня ядро не компилируется,
ну так он же не может проверить все комбинации.

--
пишите, пишите.

Блин, лучше бы квоты на cpu time % и на block io/sek сделали... Может, заняться, когда время будет?

У меня тачка при старте Х повисла. Это наверное из-за nVidia driver-а

А он поверх старого патча или поверх оригинального ядра?

Поверх оригинального (vanilla) 2.4.17

Следующая версия:

http://people.redhat.com/mingo/O(1)-scheduler/sched-O1-2.4.17-A2.patch

> Блин, лучше бы квоты на cpu time %
А почитай внимательно описание патча. Он и эту проблему отчасти решает.

> Может, заняться, когда время будет?
Издеваешься?

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

Да да точно так все виснет при запуске мозиллы в иксах.
И при ребуте вроде как не все у него путем. В общем он пока не в рабочем состоянии даже под десктоп.
Тестил 2.4.17 c gcc-3.03
Первый раз у меня Debian unstable в иксах завис.

Старая версия патча не дружила с loop, reiserfs, raid. Это только то что я заметил. Новую версию пока не тестировал. Но что-то у меня уже отпало желание играть с этой ерундой, сыра она пока ещё.

Slyder

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

на рабочие сервера ставить ядра не от производителя дистрибутива - удел
ядреных девелоперов. Или пионеров не понимающих чего они делают.

Что касается патча, то к небрежности в написании кода у Инго теперь еще
добавилась привычка писать так, что понять, что же он хочет сделать, мне
например, не по силам :-)

Пробовал 2.2.17...A2:
- mozilla действительно не работает (все сразу стопорится), хотя Alt-SysRq спасает;
- субъективно (да и объективно тоже думаю) диск стал чаще шуметь (не знаю почему, но загрузка программ, особенно параллельно на 2.2.17 проходила тише);
- этот патч накладывается на голое 2.2.17 без ошибок, сборка проходит нормально (loop использую);
- прибавки в скорости я не заметил;
- на рабочие сервера советую ставить ядра не от "производителя дистрибутива", а с сайта www.kernel.org (хотя в некоторых дистрибутивах это ядро и лежит, пример - Slackware);
- в целом не понятно, что такое шедулер ... патч правит несколько файлов в нескольких местах, причем изменения по количеству кода небольшие.

Поделюсь горьким опытом по установке schedulerа (А2) на 2.4.17. Установился нормально, компиляция прошла без проблем. При попытке скопировать СД на лету cdrdao (--on-the-fly) машина самопроизвольно перегрузилась :-( Давненько я такого под Линуксом не видел. После этого решил скопировать диск старым способом, т.е. сначала создав образ на винте - во время записи ядро на ровном месте вдруг "запаниковало" ругаясь на Interrupt Handler. Помог только reset. Болванка была отправлена на свалку. Вот такие результаты. А пока он и работал, скажу честно, я никакого изменения не ощущал вообще. ИМХО, очень он пока сырой.

Андрей Овчинников

Экие вы пессимисты. Помниться preamptible patch (или как там его)
тоже не сразу стал стабильным. А на DB или Web - сервер и сейчас нельзя.

Но главное - это идея.
:-)

> - на рабочие сервера советую ставить ядра не от "производителя
> дистрибутива", а с сайта www.kernel.org (хотя в некоторых дистрибутивах
> это ядро и лежит, пример - Slackware);

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

угу а как редхат gcc тестирует так это вообще ;)
лучший gcc на дороге ;)

Да успокойся ты, блин. Юзай редхатовские ядра если нравится, тока не возводи их в абсолют.
Я расскажу как я ставлю ядра на сервера. Пробую новые ядра сначала на десктопе, в условиях
максимально приближенных к реальным. Читаю внимательно lk-ml, накладываю предложенные патчи
если требуется. Опять тестирую жестоко разными серверными crash-тестами.
Затем, если ядро выдерживает эти тесты ставлю его на тестовый сервер.
Через три месяца, если все нормально, то ядро ставится на рабочие сервера.
Твоему редхету даже не снилось такое качественное тестирование.

> Через три месяца, если все нормально, то ядро ставится на рабочие сервера. > Твоему редхету даже не снилось такое качественное тестирование. чтож они долбоебы могут дистрибутив создать, а оттестировать так качественно как ты не могут ...

No Flame!!! No Holy Wars!!!
---------------------------
Ну не знаю ... у RedHat бывало, что они выпускают новый дистр через неделю после выхода новой версии ПО. Пример ПО - ядра, Xfree, KDE.

3-мя месяцами там и не пахнет ...

A kto skazal , chto RH - ochen rulnij i kachestvennij distr. Glukavenkij on odnako.

помню помню ;) был thread в новости о выходе RH7.0 %) помню глюки о которых нам ведали юезры решившиеся на такой смелый шаг как установка сабжа. имхо ядро не патченое производителем дистрибутива гораздо лучше чем патченое. чем мне нравится слак, так это тем что там действительно вначале тестируют потом включают в релиз. а core софт включённый в rh с -beta возле версии это не серьёзно.

а насчёт патча, так таки действительно подождём. идея имхо как минимум интересна и патч имеет право на существование. и при некоторой доработке может быть включён в 2.5.х но не в 2.4.х

> чтож они долбоебы могут дистрибутив создать, а оттестировать

Потому что при всем желании невозможно оттестировать все конфигурации
для десятков тысяч долбоебов, которые этот редхат купят. Грамотный админ отлично знает,
в каких условиях будет работать его сервер, и он может очень качественно
оптимизировать и оттестировать ядро под эти условия. Я сказал _грамотный_ ;)

Kstati o flame na gcc 3.0.2 tipa sho pod nih jadra ne sobirautsa etc. na ftp.slackware.com v current on lezit oh kak davno.

Kstati o flame na gcc 3.0.2 tipa sho pod nih jadra ne sobirautsa etc. na ftp.slackware.com v current on lezit oh kak davno.

Он лежит в качестве дополнительного, для тестирования, а не для сборки ядер.

Ivanich , eto podderzivaemij soft v slack-current , ja nim dohuja jader sobral , i vse stabilno , i esli u mena sound visnet na vseh ot 2.4.14 to ne izza gcc tak kak 2.95.3 to ze samoe , i dla kakogo testirovania??? Eslib dla testirovania , to tam bi sejcas lezal gcc 3.0.3 i jadra novie, i eshche kuca softa i uz temboee gtk , glib etc.

трёп по поводу патча

На кернел-трап по поводу патча идёт обмен мнениями (Линус участвует тоже): http://kerneltrap.com/article.php?sid=467

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.2-C1.patch
http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-C1.patch

only minimal fixes were added to the code, the goal is to reach a stable base.

Changelog:

 - fixed the mozilla crash, forgot to revert the ->prio value in
   setscheduler() which caused a wrong index ... (many thanks go to Pawel
   Kot for testing this out.)

 - fixed a load balancer bug that would get the runqueue count incorrectly
   if there is a RT running. With this fixed a 2-CPU system is completely
   usable even if a RT task is taking up 100% CPU time on one of the CPUs.

 - fix the sys_sched_yield export in ksyms.c (Davide Libenzi)

 - adds an RT event counter to optimize RT scheduling. (Davide, me)

о, это уже лучше, завтра проверю, а щас спать пора :-[ ]

Хммм работа идет глядишь и будет новый scheduler в ядре.

2Settler:

Хочешь сказать что уже можно сносно работать?

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