Really Simple Really Fair Scheduler

> Учи матчасть! Планировщик ввода-вывода на каждый блочный девайс отдельный. И на каждый сетевой интерфейс тоже.

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

> Мысль вслух: а почему бы не вешать планировщики задач по одному на каждый процессор...

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

> Сначала скажите что вы курите.

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

Осилили написание шедулеров... Ждём войну шедулеров и возможность их смены в рантайме.

> Мысль вслух: а почему бы не вешать планировщики задач по одному на каждый процессор...

Уже, DragonflyBSD. Диллон, я думаю, мог бы много чего полезного этим клоунам с *FS посоветовать.

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

Тьху.

>> Мысль вслух: а почему бы не вешать планировщики задач по одному на каждый процессор...

> Уже, DragonflyBSD.

А как там с миграцией задач между процессорами? Смигрировавшая задача неожиданно начинает шедулится совсем по другому?

Ни малейшего понятия

> СБНЧСОПСПП

+1

А две звезды не многовато?

Мудаки, блин, велосипедисты красноглазыя...

Верните Кона!

Новый вид спама : "We can offer you the MOST fair scheduller! By it only for xxx$!" =)

> Сеть у меня есть, а планировщика нет.

Да есть там планировщик, есть, успокойся. Зайди в админ-раздел, там почти треть вопросов о том, как задавить и выделить полосу с той, или иной политикой.

Enlarge your process queue!

:-)

аха, зачот :)))

:D

Предлагаю Чиста Канкретный Шедулер.

> Поправь меня, если я ошибаюсь, но QNX никогда не была даже лидером рынка - всегда были другие системы (VxWorks, всякие там OS-9, LynxOS и прочие).

Раньше он был лидером (QNX), но в другом сегменте.

> С этим никто не спорит, и технологии у нее продвинутые и "красивые". Но Линукс ее сожрет, ИМХО :)

Да, бытует такое мнение, но вот практика показала обратное. В нише встраиваемых систем с РВ два года назад очень активно развивался линукс. На что QSS спокойно заявили, мол наиграетесь - возвращайтесь, мы вас ждем. В последнем году по некоторым данным в данном сегменте рынка открытые системы сдали 15%, где достаточно вальяжно разместился QNX. Повлияла проблема, которую тяжело с самого начала осознать. Дело в том, что Линукс - очень динамичная система и это несомненно плюс, но вот вышла заплатка (очень хорошая и приятная), установил ее - пересертифицируй систему (что по оценкам - >400% всех затрат на разработку). Есть бага - это личные проблемы разработчика. Временные показатели далеко не те, что в QNX. Конечно есть MontaVista, но не смотря на положительную тенденцию они отказались от идеи продолжать снижать время отклика на прерывания. Да и к тому же это уже не совсем открытая система, и не из дешевых.

> Раньше он был лидером (QNX), но в другом сегменте.

Я говорил о всём рынке... а в каком сегменте QNX был лидером и когда? И кто лидер сейчас (я давно не слежу за статистикой)?

>> С этим никто не спорит, и технологии у нее продвинутые и "красивые". Но Линукс ее сожрет, ИМХО :)

>Да, бытует такое мнение, но вот практика показала обратное.

Еще ничего не закончилось :)

> В последнем году по некоторым данным в данном сегменте рынка открытые системы сдали 15%, где достаточно вальяжно разместился QNX.

А сколько перед этим сдал QNX? 8)

> Повлияла проблема, которую тяжело с самого начала осознать. Дело в том, что Линукс - очень динамичная система и это несомненно плюс, но вот вышла заплатка (очень хорошая и приятная), установил ее - пересертифицируй систему (что по оценкам - >400% всех затрат на разработку).

О каких заплатах речь? Новых версиях ядра? Их не обязательно использовать. Заплатах безопасности? Ну так они и в QNX должны быть.

> Временные показатели далеко не те, что в QNX.

Есть где-нибудь сравнение QNХ и того же MVL 5? А то пока я видел только сравнения разных проприетарных RTOS.

> У QNX'а был свой, весьма неплохой сегмент рынка, но, со сменой владельца, он стал его терять.

Не то, чтобы терять...наоборот - набирать. И еще прибавился новый сегмент.

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

Вызывающе неверная информация! Графическая подсистема изменена была только в TDK. Был реализована непосредственная адресация, вместо модели сигналов (которые очень затратны для графической подсистемы, что снижает производительность, несмотря на ряд плюсов). Но сделано это было вовсе не для десктопов. Там из десктопных только несколько не новых интеловых чипсетов (Extreme2). Это было сделано только потому, что спецификации были открыты. Но самым главным стали карточки Carmine и Coral, которые используются в....автомобилях. Таким образом в первую очередь эта технология для систем навигации в автомобилях. Для них же (в первую очередь) и реализовался OpenGL ES.

> А само по себе это чудо мало что умеет, кроме микроядерности и повремёнки. Но с развитием uLinux'а QNX кажется, по сравнению с ним, сущим DOS'ом.

Мух от котлет надо отделять :) У них разные векторы развития. Я с ходу могу назвать технологии QNX, до которых открытым системам в области встраиваемости еще пилить и пилить.

У меня работает FSRFS Fuckingly Simple Really Fair Scheduler

> Я с ходу могу назвать технологии QNX, до которых открытым системам в области встраиваемости еще пилить и пилить.

Давай, и поподробнее (или со ссылками :))

> Это может не DOS, а программа, исполняющаяся поверх DOS и берущая на себя часть функций ОС (а инверсия приоритетов проявляется в полный рост - как там назывался тот флаг, DOSOK ? :D).

"In DOS"

Циферки: http://lkml.org/lkml/2007/8/30/307

>lefsha По сетевым планировщикам кури http://gazette.linux.ru.net/rus/articles/taleLinuxTC.html

> Я говорил о всём рынке... а в каком сегменте QNX был лидером и когда? И кто лидер сейчас (я давно не слежу за статистикой)?

Он лидировал в станкостроении, еще раньше - не знаю.

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

> Еще ничего не закончилось :)

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

> А сколько перед этим сдал QNX? 8)

Не скажу в цифрах. Помню что много. Но подпирали не только открытые системы. Еще подпирал микрософт, и собственные поделки (крупные корпорации решили, что им дешевле свое написать, некоторые в этом приуспели. А харман посчитали и решили, что им проще купить QSS, чем постоянно лицензии у них покупать).

> О каких заплатах речь? Новых версиях ядра? Их не обязательно использовать. Заплатах безопасности? Ну так они и в QNX должны быть.

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

> Есть где-нибудь сравнение QNХ и того же MVL 5? А то пока я видел только сравнения разных проприетарных RTOS.

Сложный вопрос. Может и есть. Я сам лично сравнивал на ARM. Результаты противоречивые. В брошурке с MVL идет таблица с временами. По ним и ориентируюсь. Если говорить о сравнении, то по времени реакции QNX был лучше, но была ненормально-аномальная загрузка проца на моих тестах (зависила от фаз луны и пр). Видимо проблема была в том, что приложение для тестирования не было родным, а было портировано из линукса с различными обертками. Я думаю, что в том приложении были проблемы с памятью при тестировании (некорректная обертка над адресацией, поэтому когда запускали удаленное соединение они боролись между собой за память). К сожалению я не разработчик, поэтому достоверно не знаю, что там происходило. Но клиент просил именно сравнения этого приложения (несмотря на отсутствие родного под QNX).

PS: клиент тот сейчас на QNX.

>Мудаки, блин, велосипедисты красноглазыя...

>Верните Кона!

Хороший анестезиолог в команде kernel-developer'ов сейчас уже на вес золота =)))

помнится когда то забава такая была - два разных процесса в памяти пытаются уничтожить друг друга и захватить всю память :)

предлагаю другую забаву - два разных шедулера пытаются отъесть максимально больше процессорного времени :) кто все отожрал - тот и выиграл

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

Каких? Возможности ставить приоритет? man ionice

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

Ну так и есть, на каждый блочный девайс свой планировщик: cat /sys/block/*/queue/scheduler

> Сеть у меня есть, а планировщика нет. На каком таком простите основании.

Все там есть, зайди в раздел конфигурации ядра: Networking -> Networking options -> QoS and/or fair queueing там куча планировщиков на выбор. Больше чем есть для процессора и для I/O.

> Давай, и поподробнее (или со ссылками :))

Не пользы для, а флэйма ради? :) Я думаю, что на сайте QNX можно найти описание технологий.

Из старых технологий очень нравится Critical Process Monitoring - особый менеджер (HAM), который следит за критическими процессами. Запускается в двух экземплярах и мониторит сам себя. Если один из процессов HAM умирает, второй его перезапускает с полным востановлением всех данных. Когда запускается критический процесс (указание хаму на него), хам начинает его мониторить. Диагностика смерти процесса очень разнообразная, от активного мониторинга, до отсутствия "сердцебиения" (специальный сигнал, переодически посылаемый процессом). Фишка в том, что процесс становится неубиваемым вообще. Все данные приложения сохраняются и восстановленный процесс наченает работать с того момента, когда он умер (вплоть до временных интервалов). Так же в случае блокировки процесса он перезапускается.

Есть технология Multi-core, аналогов в проприетраных встраиваемых системах пока нету. Думаю понятно по названию о чем идет речь (многоядерные процессоры). Там же есть возможность смотреть миграцию потоков и соответственно подумать над смыслом переписать приложения, для минимизации миграции.

Так же много вкусностей вроде полного профилирования системы (обсчет до 10e-9 секунд, очень полезно для боевых программ). Совместный дебагинг распределенных приложений (реализован над эклипсом, не знаю вошел ли он в основной эклипс).

Самая вкусная на сегодня технология ИМХО - Adaptive Partitioning. Это бюджетирование процессора. Т.е. есть группы процессов (условно обсчет, мониооринг и диагностика). Как это выглядит в реальных системах? У каждой группы процессов есть потоки с различными приоритетами (и высокие и низкие). В сложной системе начинается жонглирование приоритетами для достижения нужного результата. Что мы можем в этой технологии? Мы можем сказать, что для мониторинга используется - 10% процессорного времени, диагностики - 40%, остальные 50 - обсчет системы. Процессы запущенные в этих бюджетах не будут переиспользовать процессор, если нету свободных ресурсов. Т.е. можно гарантировать, что группа процессов получит (если ей надо) не менее установленного количества процессорных ресурсов. Все процессы в рамках бюджета пользуются обычной системой приоритетов и планировки - как будто они исполняются на отдельных процессорах. Система ведет себя как обычно если нет полной загрузки процессора. Очень красиво с этой технологие бороться с DDOS-аттаками и быстрой работы системы восстановления (у них всегда есть процессорное время, даже если система полностью забита). Красиво можно разрабатывать очень сложные системы (каждая подсистема тестируется в рамках бюджета - никаких неожиданностей при сборе всех подсистем воедино).

На самом деле это только примеры. Возможностей - выше крыши.

PS: это не реклама :)

>> Давай, и поподробнее (или со ссылками :))

> Не пользы для, а флэйма ради? :)

Интересно мнение "из окопов" :)

> Critical Process Monitoring - особый менеджер (HAM)

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

Ну, HAM ~= Heartbeat (правда, там данные вроде не восстанавливаются), Multi-core в линуксе давно есть, профилирование ~= oprofile, Adaptive Partitioning ~= process containers (но эта фича пока в разработке).

Интересно было бы сравнение технологий от людей, которые использовали и QNX, и Linux.

В общем, время еще покажет :)

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

Да, там пара вызовов, один обработчик и при варианте с Heartbeat еще одна функция.

гыгыгы

> Мысль вслух: а почему бы не вешать планировщики задач по одному на каждый процессор

Придется блокировать режимы межпоточного(процессного) взаимодействия, если потоки(процессы) выполняются на разных CPU

> там пара вызовов, один обработчик и при варианте с Heartbeat еще одна функция.

Хм, и при этом оно умудряется восстанавливать данные?

> Да есть там планировщик, есть, успокойся. Зайди в админ-раздел, там почти треть вопросов о том, как задавить и выделить полосу с той, или иной политикой.

Не нашел. Мне не нужна политика. Мне надо выделить доступ для конкретного процесса. Например skype должен получить real-time доступ. а вот firefox или программы для скачивания минимальный приоритет.

> Хм, и при этом оно умудряется восстанавливать данные?

Да, ибо данные востанавливает менеджер, а не приложение следит за данными.

скоро придёт RMS и сделает свой тру планировщик GNU/RMS (Real Multitasking Scheduler) и все помирятся :D

> данные востанавливает менеджер, а не приложение следит за данными.

но это значит, что данные хранятся не в приложении, а в менеджере?

> но это значит, что данные хранятся не в приложении, а в менеджере?

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

> Мне не нужна политика. Мне надо выделить доступ для конкретного процесса. Например skype должен получить real-time доступ. а вот firefox или программы для скачивания минимальный приоритет.

Ну так сделай политику для приложений, используя в iptables --cmd-owner и MARK можно маркировать пакеты идущие от определенных программ, а по маркировке уже шедулить и выставлять приоритеты через тот же htb или другой планировщик.

> Например skype должен получить real-time доступ

За такие примеры тебя в психушку надо отправить, а то и в биореактор!

С чего это вдруг? Что именно не нравится?

Меня лично не устраивает, что надо отключать все что связяно с инет, чтобы нормально говорить.

> Самая вкусная на сегодня технология

НЕ БЫВАЕТ ВКУСНЫХ ТЕХНОЛОГИЙ !!!!!!!

Учите русский язык.

Они - киборги. Они заполонили планету. (С) А. Рева.

> НЕ БЫВАЕТ ВКУСНЫХ ТЕХНОЛОГИЙ !!!!!!!

> Учите русский язык.

Капс поможет перевести буквы в нижний регистр (когда отключен) - учите основы работы с компьютером.

Если нечего написать по существу - лучше ничего не писать. Читайте наконец этикет общения в интернете и правила форумов.

> Меня лично не устраивает, что надо отключать все что связяно с инет, чтобы нормально говорить.

Это проблема исключительно скайпа и лично твоей системы.

> Да, вот только в DOS такое было возможно без особого геморроя

Гы-ы-ы... В ДОС? Возможно? Только если её использовать исключительно в качестве загрузчика...

> Знаю не мало примеров реализации rt систем на DOS, доработанном напильником естественно, вполне успешно себе работающих.

Что там осталось от ДОС после перетачивания под rt? Формат главной загрузочной записи?