| 1.5, Аноним (-), 17:32, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Linux стал немного ближе к операционным системам реального времени? Хорошая новость!
| | |
| |
| 2.19, ABATAPA (ok), 22:08, 13/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Просыпайтесь.
Куда уж ближе. Реализации "жесткого" и "мягкого" RT для ядра были еще в прошлом веке.
И да, SCHED_DEADLINE - это еще не RT.
| | |
| |
| 3.38, Аноним (-), 09:15, 14/02/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Просыпайтесь.
> Куда уж ближе. Реализации "жесткого" и "мягкого" RT для ядра были еще
> в прошлом веке.
> И да, SCHED_DEADLINE - это еще не RT.
"Они изобрели Solaris Sheduler! Сволочи...." (С) :))))))
| | |
|
|
| |
| 2.13, Crazy Alex (ok), 18:51, 13/02/2013 [^] [^^] [^^^] [ответить]
| +9 +/– |
 Клоунам место в цирке. Этот пост - наглядная демонстрация... Иди лесом, студентик от MS, кормить тебя здесь не будут.
| | |
| 2.16, piteri (ok), 18:55, 13/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Ваш комментарий поразительно точно соответствует вашему нику.
О планировщиках задач лучше читать в соответствующей литературе а не в википеди.
>на кой чёрт лепить антикрыло от Формулы-1 на Камаз?
>Разные задачи - разные решения. И преподность это как преимущество алгоритма...
В новости всё написано, вам лень читать?
| | |
| 2.58, pavlinux (ok), 01:49, 15/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > ОСРВ обязаны гарантировать
Я те гарантирую, что в Linux задержка равна 10000 мкс (+/- 9999 мкс);
> (например, гарантировать выполнение задачи 10 мс в интервале 100 мс)
Кстати, новость поправьте, там микросекунды (мкс), а не миллисекунды (мс)
| | |
|
| |
| 2.60, pavlinux (ok), 02:37, 15/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это всё потуги чайников пытающихся выделится!
А вакуумный прирост вакуумной отзывчивости - это Плацебо, после часов траха с этими ядрами.
Если бы они тщательно тестировали всё эти патчи,
и ваще понимали чё там внутри, то они бы не юзали этот мусор.
Исключение TuxOnIce, да и то непонятно нахер нужное, при загрузке и выключении линя за 10 сек.
BFQ - тупилово.
BFS - тормозилово (работает на одно-двуядерных, больше - провал)
UKSM - глюкалово (включите отладку ядра (kobject) и узрите NULL-dereferences по команде mount)
| | |
| |
| 3.64, fidaj (ok), 12:14, 15/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > BFQ - тупилово.
а что же тогда за графики тестов автор показывал?
хотя на личном опыте вижу - что как-то оно не сильно быстрее...
а что у себя используешь для В/В?
> BFS - тормозилово (работает на одно-двуядерных, больше - провал)
но оно пока единственное на чем комфортно более-менее... на дедлайне пока паникует и виснет...
> UKSM - глюкалово (включите отладку ядра (kobject) и узрите NULL-dereferences по команде
> mount)
да и толку от него не особо...
| | |
| |
| 4.66, pavlinux (ok), 17:36, 15/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> BFQ - тупилово.
> а что же тогда за графики тестов автор показывал?
Ну надо же было проверить, мож чего и придумали.
> да и толку от него не особо...
Самое интересное внутри этой троицы, по сути это стандартные CFQ, CFS, LKMS,
но со своей математикой, типа вместо 2+2, делать 2*2 или 2 << 2;
Вот DEADLINE гораздо интереснее.
| | |
|
|
|
| 1.11, ВовкаОсиист (ok), 18:11, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 в прошлый раз(емнип с предыдущей новости) загрузится до кед с ихним ядром так и не вышло. Кернел паник %)
| | |
| |
| |
| |
| 4.35, Аноним (-), 05:31, 14/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Будет проще, если сменить дистрибутив
А если болит голова - вы срочно собираете гильотину?
| | |
| |
| 5.61, pavlinux (ok), 02:43, 15/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Будет проще, если сменить дистрибутив
> А если болит голова - вы срочно собираете гильотину?
Из окна быстрее, если конечно не первые этажи.
| | |
|
|
| 3.20, ВовкаОсиист (ok), 23:03, 13/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Нет, небыло времени. А сейчас опять тянуть из гита тонны кода, с моими то интырнетами, мне влом. Надо бы осилить найти контакты ихнии да предложить делать патчи отдельно. У меня есть сорцы ядра 3.8rc7, зачем мне ещё одно тянуть %) Интересно оно мне тем, что в тех самых ступорах при I/O операциях, винят штатный планировщик. Хотя от смены на BFS особых различий небыло, теже ступоры ...
| | |
| |
| 4.23, sdfsfsf (?), 23:26, 13/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
В новости есть ссылка на lkml и на github. И там, и там можно взять патчи.
| | |
| |
| 5.24, ВовкаОсиист (ok), 23:59, 13/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Main branches:
> - sched-dl-V7: this patchset on top of tip/master.
в том бранче исходники, и никаких *.patch я не вижу.
| | |
| |
| |
| 7.29, sdfsfsf (?), 01:42, 14/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Хотя нет, понял тебя. Тебе нужно просто научиться использовать git, что б не качать тонны кода.
| | |
|
|
|
|
|
| 2.34, ВовкаОсиист (ok), 03:34, 14/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
поставил, загрузилось до кед в этот раз. Банальный тест
$ dd if=/dev/zero of=~/ololo bs=1M count=1024
заблокировал все, кроме мышки. Пока не записало 1 гиг нулей, ничего запустить не удалось. Ещё хуже чем с cfs, аднака.
| | |
| |
| 3.40, Аноним (-), 09:18, 14/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> поставил, загрузилось до кед в этот раз. Банальный тест
> $ dd if=/dev/zero of=~/ololo bs=1M count=1024
> заблокировал все, кроме мышки. Пока не записало 1 гиг нулей, ничего запустить
> не удалось. Ещё хуже чем с cfs, аднака.
Синдром NIH сроду ни до чего приличного не доводил. Дуракам же предшественники не писаны. Осилить пару книг (таких, знаете, на бумаге напечатанных) о планировщиках ядер и вообще работе ядер - им слабо.
| | |
|
|
| 1.17, skybon (ok), 19:16, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов с CFQ - былинный отказ поэтому пользуюсь deadline.
| | |
| |
| 2.18, Anonym (?), 21:23, 13/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов
> с CFQ - былинный отказ поэтому пользуюсь deadline.
Любопытно... А на какой (исходной - целевой, если разные) файловой системе сие происходит, если не секрет? И примерный размер файла? А то я на xfs и ext3 регулярно 120-150 Гб бекапы туда-сюда копирую, и что-то такого не замечал...
Или Вы ФС через FUSE монтируете?
| | |
| |
| |
| 4.26, Anonymous1 (?), 00:12, 14/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Через mc копирует по фтп через fuse :)
Дадада, и при этом из окна консоли в иксах... При всяких аконадях, непомуках и 300 процессах console-kit-daemon...
А сетевое соединение через Йоту и пень-колоду, однако...
| | |
|
|
| |
| 3.25, Anonymous1 (?), 00:07, 14/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если это мне, то серьезно... И при чем тут самоубеждение, неясно. Если ожидается запись в один поток и много чтений - то ext3, если много процессов пишут на диск и много читают - xfs. Только agsize=4g при форматировании тома xfs не забыть... А проблемы с планировщиком, на мой взгляд, сильно надуманы - правильное форматирование и монтирование ФC c разумными параметрами вполне достаточно для отсутствия пауз. Конечно, если ФС не монтирована через FUSE.
| | |
|
| |
| 3.41, Аноним (-), 09:19, 14/02/2013 [^] [^^] [^^^] [ответить]
| –6 +/– | |
> в статье речь о планировщике задач, а не о планировщике ввода/вывода
Тюююююууууууууу?! А чья, по-твоему, функция - ввод-вывод?
| | |
| |
| 4.44, Аноним (-), 12:05, 14/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Тюююююууууууууу?! А чья, по-твоему, функция - ввод-вывод?
Тю-тю, ввод-вывод планируется [b]другими[/b] планировщиками.
| | |
| |
| 5.45, Аноним (-), 13:55, 14/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Это в каких-таких осях так плодят сущности? Процессор, значит, один и тот же, а планировщики - разные? Ну и дела-а-а-а-а..... Оказывается, на каждый чих и пых свой планировщик в вашей оси? Вот это даааааааааааааааааа!
| | |
| |
| 6.48, Crazy Alex (ok), 15:45, 14/02/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
Чего курили? Не, если вы думаете, что формироавние очереди запросов диску и арбитраж доступа задач к процессору должен делать один и тот же компонент - это великое открытие, бесспорно.
| | |
| |
| 7.53, Аноним (-), 18:40, 14/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Cправедливости ради, в теории оно бы не помешало, если есть корреляция между этими событиями, например если заранее точно известно что какая то задача гарантировано захочет CPU через 3 милисекунды после запроса чтения, если это учесть то можно сэкономить ресурсы. Другое дело что это очень сложно. Вообще, в идеале в жадеком будущем пранировщики будут аппаратными, ведь кинуть один проводок и триггер гораздо проще чем городит ту современную жуть с мозговывернутыми семафорами мутексами и эвристиками. За один-два такта сигнал пробежал по кристаллу - результат готов. В настоящем РЕАЛЬНОМ ВРЕМЕНИ.
| | |
|
|
|
|
| 3.49, ВовкаОсиист (ok), 15:58, 14/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну если ты не осилил понять, то можешь сходить на багзиллу kernel.org и почитать багрепорт под номером 12309. Задачи голодают не от планировщика ввода-вывода, а от не правильной работы планировщика процессов.
| | |
| |
| 4.50, Crazy Alex (ok), 16:58, 14/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, сходить стоит. Увидите, что статус бага - FIXED. А то, что в него кучу unrelated мусора напихали - вопрос другой и к 12309 отношения уже не имеющий. Как и к планировщикам процессов.
| | |
| |
| 5.51, ВовкаОсиист (ok), 17:55, 14/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну если кроме как сходить, ещё и почитать, то можно увидеть, что этот баг никуда не пропал. А закрыли его, так как синдромы отношения к 12309 не имееют, но в простонароде уже привыкли его называть 12309.
| | |
| |
| 6.52, Crazy Alex (ok), 18:24, 14/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну так в том числе оно не имеет отношения к (нынешним) планировщикам процессов.
| | |
| 6.54, Аноним (-), 18:44, 14/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Ну если кроме как сходить, ещё и почитать, то можно увидеть, что
> этот баг никуда не пропал. А закрыли его, так как синдромы
> отношения к 12309 не имееют, но в простонароде уже привыкли его
> называть 12309.
Это простонародье зовется "у меня тормозит комп, венду переустановил, не помогло, линукс переустановил - не помогло, но я точно знаю это двенадцатьтристадевять. Просто знаю и все."
| | |
|
|
|
|
| 2.70, pavlinux (ok), 04:11, 20/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов
> с CFQ - былинный отказ поэтому пользуюсь deadline.
Хорошо, только это планировщики ввода/вывода, тут тема про планировщик задач!
| | |
|
| 1.42, Аноним (-), 10:40, 14/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
"Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в интервале 100 мс)"
То есть даже ядро linux-rt не гарантирует этого? Странное утверждение
| | |
| |
| 2.46, Аноним (-), 13:56, 14/02/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи
> в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в
> интервале 100 мс)"
> То есть даже ядро linux-rt не гарантирует этого? Странное утверждение
Ядро RT должно иметь полное отсутствие giant locks by design. Это во-первых. Во-вторых, оно должно иметь отсутствие невытесняемых тредов. Все это в пингвине наличествует?
| | |
| |
| 3.55, Аноним (-), 18:48, 14/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи
>> в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в
>> интервале 100 мс)"
>> То есть даже ядро linux-rt не гарантирует этого? Странное утверждение
> Ядро RT должно иметь полное отсутствие giant locks by design. Это во-первых.
> Во-вторых, оно должно иметь отсутствие невытесняемых тредов. Все это в пингвине
> наличествует?
отсутствие giant locks by design никакого отношения к этому не имеют. Можно и с гигантским семафором обеспечить предсказуемый верхний предел отклика. Просто с ним это сложнее, писанины больше.
| | |
|
|
| 1.43, anonymous (??), 11:49, 14/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Мне все проблемы с вводом/выводом решило уменьшение vm.dirty_background_bytes до 16мб. Какую связь постоянно находят с планировщиками задач - для меня загадка.
| | |
| |
| 2.47, Аноним (-), 13:57, 14/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Мне все проблемы с вводом/выводом решило уменьшение vm.dirty_background_bytes до 16мб.
> Какую связь постоянно находят с планировщиками задач - для меня загадка.
Сорц у тебя на машынке стоит. Читай его и достигнешь полного просветления.
| | |
|
| 1.57, fidaj (ok), 00:45, 15/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
блин, я приятно удивлен... по субъективным ощущениям - переплюнули zen ядро с BFS :)
класс!
интерактивность на высоком уровне!
правда на ядре 3.0... повисло всё под нагрузкой :)
а на 3.8... вообще не загрузилось - паниковало прямо при загрузке...
и да - отдельным патчем не помешало бы что бы не делать git diff
| | |
| |
| |
| 3.65, fidaj (ok), 12:20, 15/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
оно-то конечно классно :)... но на какое ядро применять? :)
нипанятна...
| | |
| |
| 4.67, pavlinux (ok), 17:37, 15/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> оно-то конечно классно :)... но на какое ядро применять? :)
> нипанятна...
3.8-rc3 было
| | |
| |
| 5.69, fidaj (ok), 18:23, 15/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> оно-то конечно классно :)... но на какое ядро применять? :)
>> нипанятна...
> 3.8-rc3 было
вот я как раз искал патчи к веткам... а они по ходу только к 3.8. - а я хотел попробовать под 3.7...
у тебя на 3.8 паникует с дедлайном при загрузке?
| | |
| |
| 6.71, pavlinux (ok), 04:12, 20/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> у тебя на 3.8 паникует с дедлайном при загрузке?
Не, дышит и работает. Феншуя не заметил.
| | |
|
|
|
|
|
|
