Анонсирована (http://permalink.gmane.org/gmane.linux.kernel/1381800) шестая версия планировщика задач SCHED_DEADLINE (https://github.com/jlelli/sched-deadline), реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времени (deadline). Из изменений, представленных в новой версии SCHED_DEADLINE, можно отметить перевод патчей для использования в качестве основы ядра 3.7-rc2 (в ближайшее время также планируется выпуск варианта для ядра 3.6.2-rt4 с патчами PREEMPT_RT) и проведение тестирования на платформе ARM.SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов. Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мсек в интервале 100 мсек) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.
URL: http://permalink.gmane.org/gmane.linux.kernel/1381800
Новость: http://www.opennet.ru/opennews/art.shtml?num=35188
Он тоже неофициальный?
>Он тоже неофициальный?Официальный
>>Он тоже неофициальный?
> ОфициальныйХрен
ktune его почемуто выставляет
> ktune его почемуто выставляетЭто не тот DEADLINE
> Он тоже неофициальный?Нет, уже давно в мейнстриме.
Вполне закономерно - специфический нишевый планировщик, по области применения практически не пересекающийся с CFQ. В отличие от якобы универсальных, а по факту - непригодных ни для чего в силу недопиленности, поделок типа BFQ и RIFS-ES.
>> Он тоже неофициальный?
> Нет, уже давно в мейнстриме.Как пешком до Китая.
> Вполне закономерно - специфический нишевый планировщик, по области применения практически
> не пересекающийся с CFQ. В отличие от якобы универсальных, а по
> факту - непригодных ни для чего в силу недопиленности, поделок типа
> BFQ и RIFS-ES.Спициалисты, хватит гнать.
Нет.
А это кто?$ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
> А это кто?
> $ cat /sys/block/sda/queue/scheduler
> noop [deadline] cfqЗдрастье, приехали. :) Это мил человек, планировщик ввода/вывода, он же I/O Scheduler.
Тут тема про планировщик задач, он же Task Scheduler
>> предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессовэто как? Для гарантированного времени выполнения, нужно чтоб общее время выполнения было не больше длительности цикла выполнения.
фраза сумбурная, но, тем не менее, написано - резервируется. Общее время тут ни при делах
> для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времениТ.е. бросать ресурс CPU на процессы, к-е вот-вот завершатся, в ущерб другим?
Странная "плюшка". В каких случаях это может быть полезно??
>>задачи, наиболее близкой к истечению крайнего расчётного времени
>на процессы, к-е вот-вот завершатсяВы совершенно не поняли, что написано в первой квоте.
Извините, в первой... чём? Вери стренджительное експрэшивание
> Извините, в первой... чём?Я и грю, первый соколик тоже ничего не понял, но мнение вякал.
В городе опять каникулы??
> Т.е. бросать ресурс CPU на процессы, к-е вот-вот завершатся, в ущерб другим?Бросать ресурсы CPU которые ближе всего к вылету за рамки гарантированного отклика. Т.е. Запрос 1 пришел 80 мс назад, а запрос 20 мс тому. Гарантированный отклик - 100 мс. В этом случае система должна отработать сначала запрос 1, а затем запрос 2.
Если же 1-й запрос пришел 50 мс назад, но гарантированный отклик для этого типа запросов 100 мс, а 2-й свалился 20 мс, но гарантир. отклик на этот тип составляет 50 мс. То тогда система должна отработать сначала 2-й запрос (на него осталось 30 мс), а уже затем 1-й (на него есть 50 мс).
Да, системы реального времени отрабатывают реал-тайм запросы в ущерб менее привеллигированным.
Имеет смысл только для систем реального времени. Для обычных домашних систем и большинства серверных приложений не применяется.
Ну запустит это планировщик процесс, даст поработать 10 мс, а потом сам же его и прибьёт, так и не дав выполнить поставленную задачу и получить результат. А если процесс успевает все, что хочет - ему с любым планировщиком хорошо, да он сам планировщик, отдаёт CPU добровольно.
Ачо, вытесняющую многозадачность уже отменили? Вы вообще-то в курсях, как работают планировщики осей?
> Ну запустит это планировщик процесс, даст поработать 10 мс, а потом сам
> же его и прибьёт, так и не дав выполнить поставленную задачу
> и получить результат.Задача отработать сигнал за отведенное время. К примеру задача управления автомобилем комплексная и длительная. Но при появлении препятствия на дороге - сигнал об этом должен быть отработан за мс. И дальше система постепенно (по сравнению с миллисекундной задержкой на обработку) исполняет полученный сигнал.
В примере сигнал это появление препятствия справа и, возможно, решение об его объезде слева. А дальше работает основная задача и в течении 100-200 мс поворачивает колеса, чем меняет траекторию движения.
Чувак, ты форумом не ошибся ли? Тут речь так-то не о RT-осях идет.... :))))))))))))))))))))))))))
Так данный планировщик как раз и помогает сделать из ядра Linux ядро подходящее для создания RT-ОС.Плюс тот же RedHat выпускает ОС на базе Linux для RealTime-обработки ;)
Это ты ошибся, не RT оси канули в лету в 70-х. Больше не надо стоять в живой очереди к считывателю с колодой перфокарт, потом 3 суток ждать результата. Сейчас ты тыкаешь мышкой и видишь резултат на экране как будт то экран живой и шевелится. Это и есть реал тайм. А бед про "гарантированное бла бла за бла бла" - это обеспечивают любые ос без ошибок. К примеру гарантировано твоя колода перфокарт будет обработана за 10000 лет, что очевидно показывает что по этому дебитьно мартетоижному определению практически любая ОС - реального времени.
Боюсь, ты кое-что путаешь. Пойди хоть к викип.дорам, почитай, что так-то называется реалтаймом. Софт и хард. М? И потом потрындим. С пониманием вопроса. Ога?
>сигнал об этом должен быть отработанДолжен быть отработан до конца. До принятия решения. До тех пор, пока процесс сам не отдаст CPU. А 10 мс зачем?
>>сигнал об этом должен быть отработан
> Должен быть отработан до конца. До принятия решения. До тех пор, пока
> процесс сам не отдаст CPU. А 10 мс зачем?Только принятие решения для обработки решения не есть принятие решения для всего приложения. Потому вся обработка и принятие решения для ОДНОГО сигнала обычно довольно короткое.
>принятие решения для ОДНОГО сигнала обычно довольно короткое.Да, да и ещё раз да.
А теперь читаем товарища выше:>ты тыкаешь мышкой и видишь резултат на экране как будт то экран живой и шевелится
И меня в самом начале:
>А если процесс успевает все, что хочет - ему с любым планировщиком хорошо
Что и требовалось доказать.
>>А если процесс успевает все, что хочет - ему с любым планировщиком хорошо
> Что и требовалось доказать.а если система будет перегружена кучей задач, то задача уже не будет "успевать все, что хочет". А в реалтайм ОС более приоритетная задача своего сигнала не пропустит, как бы ни была операционка загружена - ей гарантируется время отклика. Но там приоритетные задачи - это не проигрывание музыки в винампе.
Про приоритеты я слышал, они у меня и сейчас есть, при чём тут новый планировщик? Вопрос звучит буквально так: "Зачем 10 мс?". Приоритетная задача будет работать столько, сколько ей надо, даже в перегруженной чем-то ещё системе и с любым планировщиком. А запускать приоритетную задачу и не дать ей закончиться - не лучшее решение в любом случае.
Ну талант, https://github.com/jlelli/sched-deadline/blob/mainline-dl/ke...Функция возвращает (int), а он преобразует к (s64) :)
static inline int dl_time_before(u64 a, u64 b)
{
return (s64)(a - b) < 0;
}Мож я чё-нить не вкуриваю, но если беззнаковое (u64 a) будет больше (u64 b),
то (a-b) станет, скажем, 0xfffffffffffffabc, что явно больше нуля.
> 0xfffffffffffffabc, что явно больше нуля.нет, для signed типа это число со знаком минус.
Опа, а я-то думал это когда флаг SF==1 :)
Опа, а я-то думал, что SF, в зависимости от инструкции, сбрасывается в 0, не меняется или получает значение старшего бита результата
> сбрасывается в 0, не меняется или получает значение старшего бита результатаОпа, попытался ответить, а получилось, что рассказал, как работает флаг SF
Здаётся мне это был тонкий намёк.
Я все удивляюсь. Очень неглупый дядька с фамилией Эрланг вывел свои формулы уж больше полвека тому как, и под теорию массового обслуживания фундаментально их подложил, а народ до сих пор планировщики основываясь на "идеях" изобретает... Может книжку по ТРИ почитать просто ?
> Я все удивляюсь. Очень неглупый дядька с фамилией Эрланг вывел свои формулы
> уж больше полвека тому как, и под теорию массового обслуживания фундаментально
> их подложил, а народ до сих пор планировщики основываясь на "идеях"
> изобретает... Может книжку по ТРИ почитать просто ?Одно из двух или формулы Эрланга не очень удобно реализуются в реальности (на языке Эрлан не очень то много и пишут) или реализация хромает. Почему то развиваются монолитные ядра типа Linux, а микро-ядерные ОС, которые все такие-раз таки в теории на практике практически не используются.
>> Я все удивляюсь. Очень неглупый дядька с фамилией Эрланг вывел свои формулы
>> уж больше полвека тому как, и под теорию массового обслуживания фундаментально
>> их подложил, а народ до сих пор планировщики основываясь на "идеях"
>> изобретает... Может книжку по ТРИ почитать просто ?
> Одно из двух или формулы Эрланга не очень удобно реализуются в реальности
> (на языке Эрлан не очень то много и пишут) или реализация
> хромает. Почему то развиваются монолитные ядра типа Linux, а микро-ядерные ОС,
> которые все такие-раз таки в теории на практике практически не используются.сдается мне, что язык с дядькой никак не связан, кроме того, что назван в его честь
P.S. а с учетом того, что язык создан в недрах Ericsson, не факт, что и посвящением связан
>> Я все удивляюсь. Очень неглупый дядька с фамилией Эрланг вывел свои формулы
>> уж больше полвека тому как, и под теорию массового обслуживания фундаментально
>> их подложил, а народ до сих пор планировщики основываясь на "идеях"
>> изобретает... Может книжку по ТРИ почитать просто ?
> Одно из двух или формулы Эрланга не очень удобно реализуются в реальности
> (на языке Эрлан не очень то много и пишут) или реализация
> хромает. Почему то развиваются монолитные ядра типа Linux, а микро-ядерные ОС,
> которые все такие-раз таки в теории на практике практически не используются.Сдается мне, ты трындишь. Показать пальцем в сторону вполне себе живехоньких осей?
Микро ядра только в теории выигрывают. Да и не думаю что где то есть научные расчеты чтобы микро ядра выигрывали по быстродействию у монолитных.
> Микро ядра только в теории выигрывают. Да и не думаю что где
> то есть научные расчеты чтобы микро ядра выигрывали по быстродействию у
> монолитных.оно не должно выигрывать в скорости. Прикинь, <sarcasm>даже допускается</sarcasm>, чтобы оно проигрывало. Что и происходит из-за лишних переключений контекста (правда все хотят и надеются, чтобы проигрывало в разумных пределах). Но от него ждут другого - чтобы было надежное и живучее, чтобы ядро не умирала от кривого звукового драйвера, написанного такими как ты. И кто-то готов ради этого пожертвовать толикой производительности. В свое время я поразился QNX. Очень жалел что ее не хотели превратить в ОС универсального назначения (хотя бы планировщики задач расширить и вытеснение задач на диск прикрутить для обычных процессов). Прикинь, там даже поиграться можно было - второго квейка на нем прошел (правда, файлы ресурсов (уровни, картинки) пришлось с виндовой версии брать)
Все проще, программы пишут не для абстрактных воображаемых устройств, а для конкретных аппаратных изделий коммерческих фирм, полных компромиссов, мухляжа, вранья и ошибок в спецификациях, трюков навроде эмуляции и повторного исполнения операций при сбое, скрытом от внешнего наблюдателя. Во времена транзисторнвх микросборок еще боле менее модно окинуть взглядом как там по времени логика работает, а сейчас это просто общие догадки на основе спецификаций и полу магических статистических оценок типа "ну я пол часа тест прогнал вроде прерывание за 500 тактов успевает обработать, вот погоняю еще неделю и скажу точнее".
Для простых железок (вроде AVR тех же) вполне можно посчитать по тактам худший вариант. Если нужно что-то большее - welcome в Verilog.
У меня такое ощущение что большинство и тут отписавшихся, да и в принципе "вообще", не в курсе о наличии таких научных дисциплин, как "теория массового обслуживания", которая числится в википедии как "теория очередей" (правда в википедии теория почему-то забыли про отказы по причине "неисправности") и "теория распределения информации", что такое Пуассоновский поток и т.д. Все умными людями еще в том столетии придумано, математический аппарат создан, как для моделирования процессов так и для их исследования, бери и пользуйся.Не пользуются, наощупь ходют...
> У меня такое ощущение что большинство и тут отписавшихся, да и в
> принципе "вообще", не в курсе о наличии таких научных дисциплин, как
> "теория массового обслуживания", которая числится в википедии как "теория очередей" (правда
> в википедии теория почему-то забыли про отказы по причине "неисправности") и
> "теория распределения информации", что такое Пуассоновский поток и т.д. Все умными
> людями еще в том столетии придумано, математический аппарат создан, как для
> моделирования процессов так и для их исследования, бери и пользуйся.
> Не пользуются, наощупь ходют...Ты прав, чувак. Они - юзвери, те самые пресловутые хомяки, торчащие на порносайтах и втентаклике. Только щеки надувают и по принципу "А зато я убунту осилил поставить, я СИСОДМИН!" и гнут пальцы типо с пониманием вопроса. :)))))))))))))))))))
> бери и пользуйся.Угу, и мат ожидание и дисперсия равны меж собой,
это ж какая-то хрень получится, а не планировщик.
> Я все удивляюсь. Очень неглупый дядька с фамилией Эрланг вывел свои формулыОн использует теор. вероятностей, что для атомного реактора иль автопилота недопустимо. :)
Непонятно, где скачать патчи, а не ядро целиком.
Лучше на десктопе чем CFQ. С последним система виснет при копировании больших файлов.
CFQ: Производительность самая высокая, изза учета приоритетов. Отзывчивость(зависания) самые вероятные.
DEADLINE: Производительность средняя, изза непозволения приоритетам задавливать неприоритеты. Зато отзывчивость высокая.DEADLINE является равносправедливым.
CFQ является справедливым к приоритетам.DEADLINE нужно ставить туда, где отзывчивость важна (дестопы, realtime).
CFQ нужно ставить только туда, где нет интеракции (cервера).