Доступна (https://lkml.org/lkml/2013/2/11/373) седьмая версия планировщика задач SCHED_DEADLINE (https://github.com/jlelli/sched-deadline), реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времени (deadline). Из изменений, представленных в новой версии SCHED_DEADLINE, можно отметить перевод патчей для использования в качестве основы ядра 3.8-rc7. В процессе подготовке новой версии большое внимание было уделено тестированию, что позволило выявить и исправить серию ранее не замеченных проблем. По мнению разработчика SCHED_DEADLINE, проект уже достаточно сформировался для того, чтобы снять с него метку экспериментальной разработки. Седьмой выпуск рассматривается как последний промежуточный экспериментальный релиз, нацеленный на сбор отзывов от сообщества и представителей индустрии, заинтересованных в новом планировщике.
SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов. Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в интервале 100 мс) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.URL: https://lkml.org/lkml/2013/2/11/373
Новость: http://www.opennet.me/opennews/art.shtml?num=36103
Linux стал немного ближе к операционным системам реального времени? Хорошая новость!
Просыпайтесь.
Куда уж ближе. Реализации "жесткого" и "мягкого" RT для ядра были еще в прошлом веке.
И да, SCHED_DEADLINE - это еще не RT.
> Просыпайтесь.
> Куда уж ближе. Реализации "жесткого" и "мягкого" RT для ядра были еще
> в прошлом веке.
> И да, SCHED_DEADLINE - это еще не RT."Они изобрели Solaris Sheduler! Сволочи...." (С) :))))))
> Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в интервале 100 мс) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.Я что-то пропустил или в алгоритм переключения задач действительно встроили генератор случайных чисел для обеспечения ПРОИЗВОЛЬНОЙ задержки?
И о каком реальном времени речь? Мягком, жёстком? Другие алгоритмы, напр. своп, тоже разработаны с учётом реального времени? Если нет - то на кой чёрт лепить антикрыло от Формулы-1 на Камаз?
> Обычный планировщик задач не способен гарантировать
Прямое сравнение систем реального времени (ОСРВ) и "обычных" (они официально называются "системами общего назначения") некорректно. ОСРВ обязаны гарантировать, к ОСОН таких требований никто не предъявляет. Разные задачи - разные решения. И преподность это как преимущество алгоритма... Мда...
Клоунам место в цирке. Этот пост - наглядная демонстрация... Иди лесом, студентик от MS, кормить тебя здесь не будут.
Ваш комментарий поразительно точно соответствует вашему нику.
О планировщиках задач лучше читать в соответствующей литературе а не в википеди.
>на кой чёрт лепить антикрыло от Формулы-1 на Камаз?
>Разные задачи - разные решения. И преподность это как преимущество алгоритма...В новости всё написано, вам лень читать?
> ОСРВ обязаны гарантироватьЯ те гарантирую, что в Linux задержка равна 10000 мкс (+/- 9999 мкс);
> (например, гарантировать выполнение задачи 10 мс в интервале 100 мс)Кстати, новость поправьте, там микросекунды (мкс), а не миллисекунды (мс)
http://pf.natalenko.name/
Это всё потуги чайников пытающихся выделится!
А вакуумный прирост вакуумной отзывчивости - это Плацебо, после часов траха с этими ядрами.Если бы они тщательно тестировали всё эти патчи,
и ваще понимали чё там внутри, то они бы не юзали этот мусор.Исключение TuxOnIce, да и то непонятно нахер нужное, при загрузке и выключении линя за 10 сек.
BFQ - тупилово.
BFS - тормозилово (работает на одно-двуядерных, больше - провал)
UKSM - глюкалово (включите отладку ядра (kobject) и узрите NULL-dereferences по команде mount)
> BFQ - тупилово.а что же тогда за графики тестов автор показывал?
хотя на личном опыте вижу - что как-то оно не сильно быстрее...
а что у себя используешь для В/В?> BFS - тормозилово (работает на одно-двуядерных, больше - провал)
но оно пока единственное на чем комфортно более-менее... на дедлайне пока паникует и виснет...
> UKSM - глюкалово (включите отладку ядра (kobject) и узрите NULL-dereferences по команде
> mount)да и толку от него не особо...
>> BFQ - тупилово.
> а что же тогда за графики тестов автор показывал?Ну надо же было проверить, мож чего и придумали.
> да и толку от него не особо...
Самое интересное внутри этой троицы, по сути это стандартные CFQ, CFS, LKMS,
но со своей математикой, типа вместо 2+2, делать 2*2 или 2 << 2;Вот DEADLINE гораздо интереснее.
в прошлый раз(емнип с предыдущей новости) загрузится до кед с ихним ядром так и не вышло. Кернел паник %)
И патчи не делают...
баг отрепортили, конечно?
Будет проще, если сменить дистрибутив
> Будет проще, если сменить дистрибутивА если болит голова - вы срочно собираете гильотину?
>> Будет проще, если сменить дистрибутив
> А если болит голова - вы срочно собираете гильотину?Из окна быстрее, если конечно не первые этажи.
Нет, небыло времени. А сейчас опять тянуть из гита тонны кода, с моими то интырнетами, мне влом. Надо бы осилить найти контакты ихнии да предложить делать патчи отдельно. У меня есть сорцы ядра 3.8rc7, зачем мне ещё одно тянуть %) Интересно оно мне тем, что в тех самых ступорах при I/O операциях, винят штатный планировщик. Хотя от смены на BFS особых различий небыло, теже ступоры ...
В новости есть ссылка на lkml и на github. И там, и там можно взять патчи.
> Main branches:
> - sched-dl-V7: this patchset on top of tip/master.в том бранче исходники, и никаких *.patch я не вижу.
И на lkml типа тоже бинарники?
Хотя нет, понял тебя. Тебе нужно просто научиться использовать git, что б не качать тонны кода.
Ну вот мне не хочется изучать магию git, чтобы скачать патч.
> Хотя нет, понял тебя. Тебе нужно просто научиться использовать git, что б
> не качать тонны кода.но первый-то раз всё-равно придется скачать всё ;)
>> Хотя нет, понял тебя. Тебе нужно просто научиться использовать git, что б
>> не качать тонны кода.
> но первый-то раз всё-равно придется скачать всё ;)Если "научиться использовать git", то необязательно.
ну расскажи нам, ламерам, как не качать "все" git`ом.
> ну расскажи нам, ламерам, как не качать "все" git`ом.git help clone, ламерок
>> ну расскажи нам, ламерам, как не качать "все" git`ом.
> git help clone, ламерокНе-е-е-е, ламерок, давай команду, как вытянуть только патчи без всего ядра, (без индекса)!
---
Кому отдельные патчи, ссылка внизу http://www.opennet.me/openforum/vsluhforumID3/88645.html#59
поставил, загрузилось до кед в этот раз. Банальный тест$ dd if=/dev/zero of=~/ololo bs=1M count=1024
заблокировал все, кроме мышки. Пока не записало 1 гиг нулей, ничего запустить не удалось. Ещё хуже чем с cfs, аднака.
> поставил, загрузилось до кед в этот раз. Банальный тест
> $ dd if=/dev/zero of=~/ololo bs=1M count=1024
> заблокировал все, кроме мышки. Пока не записало 1 гиг нулей, ничего запустить
> не удалось. Ещё хуже чем с cfs, аднака.Синдром NIH сроду ни до чего приличного не доводил. Дуракам же предшественники не писаны. Осилить пару книг (таких, знаете, на бумаге напечатанных) о планировщиках ядер и вообще работе ядер - им слабо.
Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов с CFQ - былинный отказ поэтому пользуюсь deadline.
> Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов
> с CFQ - былинный отказ поэтому пользуюсь deadline.Любопытно... А на какой (исходной - целевой, если разные) файловой системе сие происходит, если не секрет? И примерный размер файла? А то я на xfs и ext3 регулярно 120-150 Гб бекапы туда-сюда копирую, и что-то такого не замечал...
Или Вы ФС через FUSE монтируете?
Через mc копирует по фтп через fuse :)
> Через mc копирует по фтп через fuse :)Дадада, и при этом из окна консоли в иксах... При всяких аконадях, непомуках и 300 процессах console-kit-daemon...
А сетевое соединение через Йоту и пень-колоду, однако...
Это вы серьёзно, или как обычно, самоубеждение - великая сила?
Если это мне, то серьезно... И при чем тут самоубеждение, неясно. Если ожидается запись в один поток и много чтений - то ext3, если много процессов пишут на диск и много читают - xfs. Только agsize=4g при форматировании тома xfs не забыть... А проблемы с планировщиком, на мой взгляд, сильно надуманы - правильное форматирование и монтирование ФC c разумными параметрами вполне достаточно для отсутствия пауз. Конечно, если ФС не монтирована через FUSE.
ну у меня и без fuse клинушка ловит.// тот самый nForce, да
в статье речь о планировщике задач, а не о планировщике ввода/вывода
> в статье речь о планировщике задач, а не о планировщике ввода/выводаТюююююууууууууу?! А чья, по-твоему, функция - ввод-вывод?
> Тюююююууууууууу?! А чья, по-твоему, функция - ввод-вывод?Тю-тю, ввод-вывод планируется другими планировщиками.
Это в каких-таких осях так плодят сущности? Процессор, значит, один и тот же, а планировщики - разные? Ну и дела-а-а-а-а..... Оказывается, на каждый чих и пых свой планировщик в вашей оси? Вот это даааааааааааааааааа!
Чего курили? Не, если вы думаете, что формироавние очереди запросов диску и арбитраж доступа задач к процессору должен делать один и тот же компонент - это великое открытие, бесспорно.
Cправедливости ради, в теории оно бы не помешало, если есть корреляция между этими событиями, например если заранее точно известно что какая то задача гарантировано захочет CPU через 3 милисекунды после запроса чтения, если это учесть то можно сэкономить ресурсы. Другое дело что это очень сложно. Вообще, в идеале в жадеком будущем пранировщики будут аппаратными, ведь кинуть один проводок и триггер гораздо проще чем городит ту современную жуть с мозговывернутыми семафорами мутексами и эвристиками. За один-два такта сигнал пробежал по кристаллу - результат готов. В настоящем РЕАЛЬНОМ ВРЕМЕНИ.
Софт - на то и софт, а не железо, что в нём мало что известно заранее. То есть дя чего-то архиспециализированного межети можно такие зависимости сформировать, но в сколько-нибудь широкой применимости я сильно сомневаюсь.ну а насчёт железных панировщиков - вы, из извините, чушь несёте.
> Справедливости ради, в теории оно бы не помешало, если есть корреляция между этими событиямиКорреляцию делают через CGROUP
Ну если ты не осилил понять, то можешь сходить на багзиллу kernel.org и почитать багрепорт под номером 12309. Задачи голодают не от планировщика ввода-вывода, а от не правильной работы планировщика процессов.
Да, сходить стоит. Увидите, что статус бага - FIXED. А то, что в него кучу unrelated мусора напихали - вопрос другой и к 12309 отношения уже не имеющий. Как и к планировщикам процессов.
Ну если кроме как сходить, ещё и почитать, то можно увидеть, что этот баг никуда не пропал. А закрыли его, так как синдромы отношения к 12309 не имееют, но в простонароде уже привыкли его называть 12309.
Ну так в том числе оно не имеет отношения к (нынешним) планировщикам процессов.
> Ну если кроме как сходить, ещё и почитать, то можно увидеть, что
> этот баг никуда не пропал. А закрыли его, так как синдромы
> отношения к 12309 не имееют, но в простонароде уже привыкли его
> называть 12309.Это простонародье зовется "у меня тормозит комп, венду переустановил, не помогло, линукс переустановил - не помогло, но я точно знаю это двенадцатьтристадевять. Просто знаю и все."
> Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов
> с CFQ - былинный отказ поэтому пользуюсь deadline.Хорошо, только это планировщики ввода/вывода, тут тема про планировщик задач!
"Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в интервале 100 мс)"То есть даже ядро linux-rt не гарантирует этого? Странное утверждение
> "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи
> в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в
> интервале 100 мс)"
> То есть даже ядро linux-rt не гарантирует этого? Странное утверждениеЯдро RT должно иметь полное отсутствие giant locks by design. Это во-первых. Во-вторых, оно должно иметь отсутствие невытесняемых тредов. Все это в пингвине наличествует?
>> "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи
>> в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в
>> интервале 100 мс)"
>> То есть даже ядро linux-rt не гарантирует этого? Странное утверждение
> Ядро RT должно иметь полное отсутствие giant locks by design. Это во-первых.
> Во-вторых, оно должно иметь отсутствие невытесняемых тредов. Все это в пингвине
> наличествует?отсутствие giant locks by design никакого отношения к этому не имеют. Можно и с гигантским семафором обеспечить предсказуемый верхний предел отклика. Просто с ним это сложнее, писанины больше.
Мне все проблемы с вводом/выводом решило уменьшение vm.dirty_background_bytes до 16мб. Какую связь постоянно находят с планировщиками задач - для меня загадка.
> Мне все проблемы с вводом/выводом решило уменьшение vm.dirty_background_bytes до 16мб.
> Какую связь постоянно находят с планировщиками задач - для меня загадка.Сорц у тебя на машынке стоит. Читай его и достигнешь полного просветления.
блин, я приятно удивлен... по субъективным ощущениям - переплюнули zen ядро с BFS :)
класс!
интерактивность на высоком уровне!правда на ядре 3.0... повисло всё под нагрузкой :)
а на 3.8... вообще не загрузилось - паниковало прямо при загрузке...и да - отдельным патчем не помешало бы что бы не делать git diff
> и да - отдельным патчем не помешало бы что бы не делать git diff1. https://patchwork.kernel.org/
2. https://patchwork.kernel.org/project/LKML/list/
3. https://patchwork.kernel.org/project/LKML/list/?submitter=Ju...Ахтунг, при нажатии начнут грузиться патчи!
[01/14] http://patchwork.kernel.org/patch/2125441/raw
[02/14] http://patchwork.kernel.org/patch/2125451/raw
[03/14] http://patchwork.kernel.org/patch/2125571/raw
[04/14] http://patchwork.kernel.org/patch/2125461/raw
[05/14] http://patchwork.kernel.org/patch/2125561/raw
[06/14] http://patchwork.kernel.org/patch/2125541/raw
[07/14] http://patchwork.kernel.org/patch/2125471/raw
[08/14] http://patchwork.kernel.org/patch/2125551/raw
[09/14] http://patchwork.kernel.org/patch/2125531/raw
[10/14] http://patchwork.kernel.org/patch/2125481/raw
[11/14] http://patchwork.kernel.org/patch/2125521/raw
[12/14] http://patchwork.kernel.org/patch/2125491/raw
[13/14] http://patchwork.kernel.org/patch/2125511/raw
[14/14] http://patchwork.kernel.org/patch/2125501/raw
спасибо, я как всегда туплю по ночам :)
оно-то конечно классно :)... но на какое ядро применять? :)
нипанятна...
> оно-то конечно классно :)... но на какое ядро применять? :)
> нипанятна...3.8-rc3 было
>> оно-то конечно классно :)... но на какое ядро применять? :)
>> нипанятна...
> 3.8-rc3 быловот я как раз искал патчи к веткам... а они по ходу только к 3.8. - а я хотел попробовать под 3.7...
у тебя на 3.8 паникует с дедлайном при загрузке?
> у тебя на 3.8 паникует с дедлайном при загрузке?Не, дышит и работает. Феншуя не заметил.
>> у тебя на 3.8 паникует с дедлайном при загрузке?
> Не, дышит и работает. Феншуя не заметил.а у меня во шо http://www.youtube.com/watch?v=16d2xJ02T0o
написал об этом в рассылку, но там что-то не разговорчивые...