Агентство NASA выбрало (http://www.linuxdevices.com/news/NS5714800202.html) Linux как основную ОС для экспериментального проекта "Dependable Multiprocessor" разрабатываемого в рамках миссии "New Millennium Program Space Technology 8 (ST8)".Благодаря проекту будет создано программное окружение, уже знакомое научным работникам, что позволит им без труда портировать научные приложения, которые можно будет использовать для управления оборудованием и проведения расчетов непосредственно на космических аппаратах.
URL: http://www.linuxdevices.com/news/NS5714800202.html
Новость: http://www.opennet.me/opennews/art.shtml?num=11133
красивые кортинки...
но вообще-то для подобных задач микроядро больше подошло бы.. понадежнее будет, все-таки
> p0vlinugz: Ещё один спИцЫалист по космическим жЫвотным...ну так, специалист :) а че
ТАМ слишком страшно надеяццо на ребут. Даже с пачкой резервов.
Все должно отрабатывать как по нотам, даже если свеже'included модуль - глючноватый...
Я - специалист. Занимаются ребята хернёй однозначно. Когда-нибудь эпоху Гейтса-Линукса будут именовать и изучать в школах как эпоху всеобщей компьютерной безграмотности и безалаберности. У этих просто ещё 6 компьютеров не висли намертво на несколько часов, как у русских на МКС. Жареный петух клюнет.
>Я - специалист. Занимаются ребята хернёй однозначно. Когда-нибудь эпоху Гейтса-Линукса будут именовать
>и изучать в школах как эпоху всеобщей компьютерной безграмотности и безалаберности.Опа-опа... Типа придет велика бздя на всия МирЪ и укажет великий свет на будуще?
Тока все по той же истории она будет на предыдущем от Линуха этапе развития - раз уж они тока щас tmpfs "изобрели" %))Мож монолитному линуху и не совсем место на обрите пока что - но пробовать то надо когда-нить. И кто как ни NASA - у них то деньжат есть чуток.
>У этих просто ещё 6 компьютеров не висли намертво на несколько
>часов, как у русских на МКС. Жареный петух клюнет.если этого петуха ремонтировать так же часто и своевременно как на МКСе - то, ессьно будет клевать ;)
Ты специалист по словесному ананизму.
Угу.
Специалист.
С сайтом, не побоюся этого слова.
ufolog.ru по таким "специалистам" плачет.
Суда по статье... ГыГ.
Ты бы, "специалист" ты этакий врубился, что на МКС произошло, ради интереса, хотябы.
а потом говорил.
Клоун.
>Я - специалист.
По словоблудию?> Занимаются ребята хернёй однозначно.
Дядьку, а вы Жириновским не работаете во внеурочное время? :)
NASA тестирует систему управления на базе "обычного" железа и софта, в смысле доступного коммерчески, а не вышитого строго под заказ. Судя по названию программы, HA предполагается обеспечить резервированием систем.При этом выбор делало не NASA (которое достаточно давно определилось с линуксом), а их контрактор Honeywell, который в линукс для аэрокосмоса залез на моей памяти впервые. Соответственно те выбрали субподрядчиком Wind River.
Заметка для думающих, что специалисты: в Wind River несколько лет тому орали, что линукс сакс (поскольку он выносил с рынка их проприетарную BSD, какая досада). Кушать продолжать захотели -- решили сменить пластинку и заняться делом, а не истерикой. Начали с покупки технологии RTLinux у FSMLabs.
"Добрым молодцам урок".
2 _Nick_: сделайте одолжение, погуглите "NASA Linux", прежде чем и сюда с микроядрами. А ещё лучше -- попользуйтесь этими самыми микроядрами да поразрабатывайте под них модули. Потом вернёмся к надёжности суммы кода.
>2 _Nick_: сделайте одолжение, погуглите "NASA Linux", прежде чем и сюда с
>микроядрами. А ещё лучше -- попользуйтесь этими самыми микроядрами
да я бы с удовольствием - да вот нет в миру такого линуха (остальные ядра не интересны - не GPL), а его создание - пока для меня неподьемная задача>да поразрабатывайте под них модули. Потом вернёмся к надёжности суммы кода.
ну, писать модули поверх готового API - дело не такое уж и сложное. Другое дело создание этого самого интерфейса...
Ну а насчет надежности - неужели сложность создания внутреннего интерфейса негативно скажеться на суммарной надежности? Чисто теоретически. Или ты именно о том, что _практически_ получиться ерунда? ;)
>>2 _Nick_: сделайте одолжение, погуглите "NASA Linux", прежде чем и сюда с
>>микроядрами. А ещё лучше -- попользуйтесь этими самыми микроядрами
>да я бы с удовольствием
Погуглили уже?>- да вот нет в миру такого линуха (остальные ядра не интересны - не GPL),
Да полно GPL'ных ядер. Вон недавно ещё что-то проскакивало по freshmeat.>>да поразрабатывайте под них модули. Потом вернёмся к надёжности суммы кода.
>ну, писать модули поверх готового API - дело не такое уж и
>сложное. Другое дело создание этого самого интерфейса...
Всё-таки почитайте документацию того же Minix или спросите профессора, как модуль-то написать. Hint: есть ещё такая штука как проблема взаимодействия N объектов. Сама их функциональность может делаться просто, но сложность взаимодействия слишком быстро растёт.>Чисто теоретически.
Я собсно намекал на то, что Ваши теоретические изыски стоят ещё меньше, чем мои теоретические изыски (которые хотя бы задевают документацию и анализы всякие) -- а мои и так почти ничего не стоят. Смысл фантазировать вслух и особенно делать уверенный вид при этом? Молодёжь на такое может купиться, будет потом бегать пару лет с пузырями про микроядра, пока не отойдёт.>Или ты именно о том, что _практически_ получиться ерунда? ;)
Я о том, что практически почти у всех именно она и получается. Хорошие реализации весьма специфичны (наложенные ограничения вроде i386 only и узкой нишевости позволяют сфокусироваться на вылизывании). Для общей же, судя по NT3.51 и Minix, это не работает. Макось разве, но она тоже относительно нишевая.
>Погуглили уже?
это мое перманентное состояние :)>>- да вот нет в миру такого линуха (остальные ядра не интересны - не GPL),
>Да полно GPL'ных ядер. Вон недавно ещё что-то проскакивало по freshmeat.
Хоть один линк в студию, плз! (Просьба не путать например микроядро L4 с микроядерным
Линухом). Сложность случая пингвинов - именно в том, что портирование всего его функционала на какое-либо микроядро - самая большая проблема.
>Всё-таки почитайте документацию того же Minix или спросите профессора, как модуль-то написать.
> Hint: есть ещё такая штука как проблема взаимодействия N объектов.
> Сама их функциональность может делаться просто, но сложность взаимодействия слишком
>быстро растёт.
Мои же слова сказанные по-другому: сложно создать API для этого самого взаимодействия.
И документацию миникса я читал. Все так же готов утверждать: написание модуля для
готового микроядра - задача в разы проще, чем создание этого самого ядра.>Я собсно намекал на то, что Ваши теоретические изыски стоят ещё меньше,
>чем мои теоретические изыски (которые хотя бы задевают документацию и анализы
>всякие) -- а мои и так почти ничего не стоят.
>Смысл фантазировать вслух и особенно делать уверенный вид при этом?
>Молодёжь на такое может купиться, будет потом бегать пару лет с
>пузырями про микроядра, пока не отойдёт.
Мои пузыри были именно о том, что микроядро (именно ядро с защитой каждого модуля путем помещения в свое адресное пространство - т.е. в отдельный процесс)
предоставляет большую надежность в сравнении с монолитом.
О сложности его создания начали вы и пытаетесь смешать мои высказывания с гразью...
Хотя, я и не отрицал бОльшую сложность разработки микроядра.
>>Или ты именно о том, что _практически_ получиться ерунда? ;)
>Я о том, что практически почти у всех именно она и получается.
Это еще не говорит о том, что сама идея гумно.>Хорошие реализации весьма специфичны (наложенные ограничения вроде i386 only и
>узкой нишевости позволяют сфокусироваться на вылизывании). Для общей же, судя
>по NT3.51
в этом чуде не было защиты адресным пространством (загрузки модулей в разные процессы)>и Minix, это не работает. Макось разве, но
>она тоже относительно нишевая.
>>>- да вот нет в миру такого линуха (остальные ядра не интересны - не GPL),
>>Да полно GPL'ных ядер.
>Хоть один линк в студию, плз!
Из того, на что может иметь смысл ссылаться -- http://atheos.syllable-norden.info/ (вчера, что ли, рядом упоминал).>О сложности его создания начали вы
Понимаете, сложность создания выливается в стоимость*надёжность. А сложность создания взаимодействующей внутри себя системы легко недооценить.>и пытаетесь смешать мои высказывания с гразью...
М-да, наверное, действительно на это похоже. Извините.
>Из того, на что может иметь смысл ссылаться --
http://atheos.syllable-norden.info
не нашел и слова об адресной защите или микроядерности.
Плохо читал список фич?
>>[AtheOS]
>не нашел и слова об адресной защите или микроядерности.
>Плохо читал список фич?
Вы вроде интересовались живыми GPL'ными ядрами, а не микро-. Я и ответил. И того, и другого сходу не припомню (ну не Hurd же).
>Вы вроде интересовались живыми GPL'ными ядрами, а не микро-. Я и
>ответил. И того, и другого сходу не припомню (ну не
>Hurd же).пока есть Линух - просто GPLные другие ядра не представляют интереса.
Интересны именно GPL микроядра.
> Всё-таки почитайте документацию того же Minix или спросите профессора,
> как модуль-то написать. Hint: есть ещё такая штука как проблема
> взаимодействия N объектов. Сама их функциональность может делаться
> просто, но сложность взаимодействия слишком быстро растёт.сложность растет, но надежность получаемого в результате решения
растет еще быстрее. и это единственная причина, почему используют
более сложное и дорогое в создании/обслуживании решение, чем Linux.тот же самый Linux - также намного сложнее, чем например, MS-DOS 3.3
но ни ты, ни кто-либо другой из современных пользователей Linux`а
почему-то не горят желанием все бросить и вернуться обратно в DOS.то расстояние, которое разделяет Linux 2.6 и MS-DOS 3.3 ты можешь
себе представить. вот примерно такая же разница между Linux и QNX.
и по сложности создания OS и по надежности работы приложений...> Смысл фантазировать вслух и особенно делать уверенный вид при этом?
> Молодёжь на такое может купиться, будет потом бегать пару лет
> с пузырями про микроядра, пока не отойдёт.QNX используют только там где действительно нужна высокая надежность.
Linux - это операционная система, которую можно использовать бесплатно.
это разные системы, разные цели, разные архитектуры. что тут сравнивать?> Для общей же, судя по NT3.51 и Minix, это не работает.
для desktop`а - это не работало в 1985, 1995 и 2005 году.
но кто точно знает, что именно будет в 2015-м, 2025 и 2035-м?посмотри какие были hardware и ОС 20-30 лет тому назад, на основании
этого примерно можно представить что будет через 20-30 лет в будущем.
>> сложность взаимодействия слишком быстро растёт.
>сложность растет, но надежность получаемого в результате решения
>растет еще быстрее.
Надёжность не растёт со сложностью.>тот же самый Linux - также намного сложнее, чем например, MS-DOS 3.3
И много где DOS до сих пор и используется.>QNX используют только там где действительно нужна высокая надежность.
>Linux - это операционная система, которую можно использовать бесплатно.
>это разные системы, разные цели, разные архитектуры. что тут сравнивать?
Именно это и хотел сказать.>посмотри какие были hardware и ОС 20-30 лет тому назад, на основании
>этого примерно можно представить что будет через 20-30 лет в будущем.
Мне -- не получается, как и 20-30 лет тому вряд ли можно было представить суперкомпьютер под кухаркиным столом. :) [косясь на свой аж одноядерный 3700+ с целым гигом]
>>> сложность взаимодействия слишком быстро растёт.>> сложность растет, но надежность получаемого в результате решения растет еще быстрее.
> Надёжность не растёт со сложностью.
разве QNX (микроядро)- это менее надежная
операционная система, чем Linux (монолитное ядро)?Cisco IOS XR (микроядро) - это менее надежная
операционная система, чем Cisco IOS (монолитное ядро)?сложность растет при переходе с монолитного ядра на микроядро.
но "надежность" получаемого решения при этом растет еще больше.>> тот же самый Linux - также намного сложнее, чем например, MS-DOS 3.3
> И много где DOS до сих пор и используется.
используется, но только не по той причине, что MS-DOS 3.3 - это более качественное
или более надежное решение, чем [RT]Linux. а только лишь потому что более дешевое.аналогично и NASA сейчас испытывает дефицит финансирования (ведь все деньги америки ушли
на военные расходы, в том числе и на "антитеррористические" операции в Ираке/Афганистане)не так давно проскакивала новость, что большое количество телескопов NASA
находится в аварийном состоянии, и требуют срочного ремонта. но денег на это нет.>> QNX используют только там где действительно нужна высокая надежность.
>> Linux - это операционная система, которую можно использовать бесплатно.
>> это разные системы, разные цели, разные архитектуры. что тут сравнивать?> Именно это и хотел сказать.
а мне показалось(?), что ты обсуждал недостатки микроядерного подхода построения ОС...
>> посмотри какие были hardware и ОС 20-30 лет тому назад, на основании
>> этого примерно можно представить что будет через 20-30 лет в будущем.> Мне -- не получается, как и 20-30 лет тому вряд ли можно
> было представить суперкомпьютер под кухаркиным столом. :)
> [косясь на свой аж одноядерный 3700+ с целым гигом]я сейчас обычно использую две-три операционки одновременно на своем компе,
это WinNT 5.2 + CentOS 4.x + FreeDOS 1.x: host OS + inside VMware Server.
и железо самое обычное - 2GB RAM, CPU P4 3.2 GHz. в 1995 году я о таком
workplace и мечтать даже не мог. а ведь прошло всего 10 лет с тех пор...в 1985 году только появился 386 процессор с аппаратной защитой памяти,
это был огромный шаг вперед по сравнению с 286 процессором. "leap ahead".сейчас - уже полным ходом идет переход на 64-разрядные процессоры,
внедряются технологии аппаратной виртуализации и паравиртуализации.за 10-15 лет переход от 16-разрядных до 64-разрядных процессоров -
такие темпы развития hardware - впечетляют. я уж не говорю о том,
как выросли быстродействие CPU, (а также объемы) RAM и HDD.
>>>> сложность взаимодействия слишком быстро растёт.
>>> сложность растет, но надежность получаемого в результате решения растет еще быстрее.
>> Надёжность не растёт со сложностью.
>разве QNX (микроядро)- это менее надежная
>операционная система, чем Linux (монолитное ядро)?
>Cisco IOS XR (микроядро) - это менее надежная
>операционная система, чем Cisco IOS (монолитное ядро)?
У меня не было возможности сравнивать QNX с Linux по надёжности и IOS XR -- вообще. Оценки SLOC собственно ядра (+/- основные серверы), не считая драйверов -- по ним у меня тоже нет. Поэтому остаётся близкое к голословному утверждение, что эти специализированные ОС жертвуют пригодностью для гораздо большего ареала, на котором водится линукс, для большей надёжности в своей нише.Что и говорил, опять же.
>сложность растет при переходе с монолитного ядра на микроядро.
>но "надежность" получаемого решения при этом растет еще больше.
У Вас есть на чём сравнивать, бишь микроядерные и монолитные (тем более модульно-ктредовые) ядра сопоставимой функциональности и трудоёмкости? У меня -- нет.>используется, но только не по той причине, что MS-DOS 3.3 - это более качественное
>или более надежное решение, чем [RT]Linux. а только лишь потому что более
>дешевое.
Помните такое слово -- good enough?>>> это разные системы, разные цели, разные архитектуры. что тут сравнивать?
>> Именно это и хотел сказать.
>а мне показалось(?), что ты обсуждал недостатки микроядерного подхода построения ОС...
Я скорее пытался подсказать недостатки некорректного сравнения камаза со свадебным фаэтоном.
>>QNX используют только там где действительно нужна высокая надежность.
>>Linux - это операционная система, которую можно использовать бесплатно.
>>это разные системы, разные цели, разные архитектуры. что тут сравнивать?
Linux последнее время имеет все шансы заменить QNX в некоторых отраслях
(встраиваемые устройства - как минимум). Причем по 2 параметрам,
где QNX не сможет уже обойти Линух пока сам не измениться: открытость исходников
и бесплатность (как пива).>>посмотри какие были hardware и ОС 20-30 лет тому назад, на основании
>>этого примерно можно представить что будет через 20-30 лет в будущем.
>Мне -- не получается, как и 20-30 лет тому вряд ли можно
>было представить суперкомпьютер под кухаркиным столом. :)
да, просто так представить невозможно куда заведет прогресс через 20-30 лет...>[косясь на свой аж одноядерный 3700+ с целым гигом]
у мсье кухарский стол по долгу службы? ;)
(шутко)
О надежности.Надежен код.А микроядро там или нет - вопрос 10-й.Микроядро лучше в плане failure recovery.Однако в космосе не должно быть ошибок.Радости то если в ответственный момент бахнется драйвер периферии?При этом может быть до 3.14... - упала вся система или нет.Дальнейшее поведение железки которой рулили не особо достоверно.Поэтому вещей типа упавшего драйвера быть просто не должно.Ни с микроядром ни без.
>О надежности.Надежен код.А микроядро там или нет - вопрос 10-й.Микроядро лучше в
>плане failure recovery.Однако в космосе не должно быть ошибок.Радости то если
>в ответственный момент бахнется драйвер периферии?При этом может быть до 3.14...
>- упала вся система или нет.Дальнейшее поведение железки которой рулили не
>особо достоверно.Поэтому вещей типа упавшего драйвера быть просто не должно.Ни с
>микроядром ни без.
несколько неверное мнение по поводу failures.
Они _могут_ быть, хоть ты крабом стань.
Но т.к. отловить их полностью крайне сложно - то тут уже идет счет на процент вероятности
возникновения ошибок и риски связанные с этим.
И вот для микроядра такая вероятность критической (невосстановимой) ошибки радикально меньше.
Про драйвер периферии. Даже если он упал и корабль выжил (допустим, это был драйвер управления солнечной батареей всего-лишь) то перезагрузка этого драйвера продолжит работу всего корабля (драйверов, отвечающих за остальные узлы) в _определенном_ состоянии, без
опасений, что во время падения драйвера солнца не был переписан какой-либо участок памяти другого модуля. Т.е. о дальнейшей работоспособности корабля _можно_ говорить.
Ну и, ессьно, образ упавшего можуля уже через пару секунд после этого события находиться на Земле, в дебаггерах пачки девелоперов, с тем чтобы быть пофикшенным и залитым опять на корабль.Вот такая маленькая фантастика :)
Мнение программиста RTS:
"Когда меня подряжают на контроллеры с Linux меня ничинает мутить: опираться в отладке на это скользкое как желе падучее Linux kernel нет никакой возможности, убогие средства отладки. Другое дело QNX: непоколебимая стойкость ко всему, хорошие инструменты для отладки."
>Мнение программиста RTS:
>"Когда меня подряжают на контроллеры с Linux меня ничинает мутить: опираться в
>отладке на это скользкое как желе падучее Linux kernel нет никакой
>возможности, убогие средства отладки.
Ну, это перегиб конечно. И "желе падучее" и "убогие средства отладки".>Другое дело QNX: непоколебимая стойкость ко всему,
ну ессьно, если ваш кривой драйвер живет в отдельном процессе - ессьно будет стойкость :)>хорошие инструменты для отладки."
про это не знаю ничего, увы.Но даже со всем этим у QNXа есть весьма заметный минус по сравнению с линухом - он не под GPL. Отсюда ограничения при внедрении (деньги/лицензии) и заточка под свои задачи (нет исходников с правом изменения). Мир неидеален....
>Мнение программиста RTS:
>"Когда меня подряжают на контроллеры с Linux меня ничинает мутить: опираться в
>отладке на это скользкое как желе падучее Linux kernel нет никакой
>возможности, убогие средства отладки. Другое дело QNX: непоколебимая стойкость ко всему,
>хорошие инструменты для отладки."Мнение прогамиста RTS опять-таки.
Живу под RTLinux и в ус не дую. С отладкой всё вполне хорошо. Ничего не глючит и не падает. Скажите, пожалуйсто, что я не так делаю?
Под QNX тоже писал, бывало. Тоже не глючит.
Этот RTLinux какой-то сильно другой что ошибки в модулях не приводят к падению ядра ?
>Этот RTLinux какой-то сильно другой что ошибки в модулях не приводят к
>падению ядра ?думаю, деление на ноль в коде любого ядра принесет массу удовольствия ;)
Вероятность ошибки в ядре размером 65KB очень мала. При малом размере алгоритм и код можно тщательно написать и тщательно протестировать.
>Вероятность ошибки в ядре размером 65KB очень мала. При малом размере алгоритм
>и код можно тщательно написать и тщательно протестировать.это уже сравнение микроядра и монолита.
Их плюсы/минусы всем уже известны.
Но вот фича в том, что даже при такой большой теоретической разнице в стабильности QNX и Линуха - последний работает достаточно надежно, и сравнимо с QNXом.
>Этот RTLinux какой-то сильно другой что ошибки в модулях не приводят к
>падению ядра ?
Этот RTLinux какой-то сильно другой, что делает hard realtime. Если Вам очень интересно, как именно -- почитайте описание, может, окажется интересней, чем на первый взгляд (как для убеждённого сторонника мелкоядер).Вообще же сравнивать тёплое с мягким не работает.
До того как какие-то обезьяны (MS?) попытались продвинуть свою обычную ОС в автомобильную промышленность (управление двигателем и системами автомобиля) классифицировав её как "Soft RTS", никому не нужно было добавлять "Hard".RTS либо Real Time, либо фуфло с этикеткой, а добавка "Hard" появилась по недоразумению. Нужны было добавлять не "Hard", а "True".
Так каким образом наличие поддержки True RT процессов убрало зависимость целостности ядра от драйверов ? Никаким.
Когда количество процессорных ядер в настольных компьютерах перевалит число 10 и монолитные ядра станут захлёбываться от попыток синронизировать большое количество одновременно выполняемых потоков в рамках одного процесса в критических секциях без катастрофического падения коэффициента использования процессора, может быть вы наконец-то поймёте, что у нас нет друго пути кроме национал-социализма. Сегодняшнее поколение для нас потеряно. Оно не простит нам голода и бомбардировок. А вот молодые, те, которым сейчас 5-6 лет это прейдётся по душе. И вот тогда-то и понадобится концепция микроядра. Достаточно будет вскинуть руку, крикнуть "Хайль" и к вам потянутся страждущие порядка и мощи.
>Когда количество процессорных ядер в настольных компьютерах перевалит число 10 и монолитные
>ядра станут захлёбываться от попыток синронизировать большое количество одновременно выполняемых потоков
>в рамках одного процесса в критических секциях без катастрофического падения коэффициента
>использования процессора, может быть вы наконец-то поймёте,
Читай новости. Линух (есьно монолит, другого пока нет) уже давно успешно шедулит тисячи процов. В разных они корпусах или на одном кристалле - не особо влияет на логику работы
(хотя для обоих случаев есть свои методы оптимизаций).
Так что, линух УЖЕ готов бегать твои 10 ядер на настольном компе и не только.>что у нас нет
>друго пути кроме национал-социализма. Сегодняшнее поколение для нас потеряно. Оно не
>простит нам голода и бомбардировок. А вот молодые, те, которым сейчас
>5-6 лет это прейдётся по душе. И вот тогда-то и понадобится
>концепция микроядра. Достаточно будет вскинуть руку, крикнуть "Хайль" и к вам
>потянутся страждущие порядка и мощи.хороша у тя трава :)
Никакого понимания.>Читай новости. Линух (есьно монолит, другого пока нет) уже давно успешно шедулит
>тисячи процов. В разных они корпусах или на одном кристалле -Тысячи процов ? В тысячах компьютеров - по одному процессору на коробку ?
>не особо влияет на логику работы
>(хотя для обоих случаев есть свои методы оптимизаций).
>Так что, линух УЖЕ готов бегать твои 10 ядер на настольном компе
>и не только.Планировать не означает эффективно использовать.
Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но с монолитными ядрами она выпячивается больше.
>Никакого понимания.
да тут гении на опеннете пропадают... :)
>Планировать не означает эффективно использовать.
Ты из какого зоопарка сбежал? :)
Эффективность использования процов в SPM системе лишь отчасти
на плечах ядра. И его задача - именно сказать кто и наком проце в каждый момент должен работать. И Лимнух это делает чудно.
А вот уже создание алгоритма например для распредленных вычислений чтобы
минимизировать простои в ожидании шины - это талант архитектора программулины,
которую будет бегать ядро.Ну, а если же есть примеры _более_ эффективаного использования SMP системы ядром,
чем у Линуха - то в студию их, плз :)
Можно на примерах этих же N-ядерных кластеров, где живут почти лишь только пингвины ;)
>Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде
>с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди
>чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но
>с монолитными ядрами она выпячивается больше.
А вот с этого места поподробнее, плз ;)
Каким же это образом принцип размещения кода модулей (в адрессном пространстве ядра или в одтельном для каждого модуля) так вот резко и главное однозначно(!!) влияет на
SMP способности ядра? :) (Это если даже забыть, что на эффективность влияет и сам пользовательский процесс не меньше ;)
Мы из разных миров.
Я из тех, для кого SM в абревиатуре SMP означает Shared Memory а не Symmetrical Multi.>Эффективность использования процов в SPM системе лишь отчасти
>на плечах ядра. И его задача - именно сказать кто и наком
>проце в каждый момент должен работать. И Лимнух это делает чудно.Проблема SMP - одновременный доступ процессоров по одному адресу. Когда на процесоры планируется выполнение кода из разных процессов это не страшно так как у каждого процесса свой участок памяти. А когда нити на процессорах проходят через один процесс, то... Если не понятно, читайте о механизмах синхронизации процессов.
>А вот уже создание алгоритма например для распредленных вычислений чтобы
>минимизировать простои в ожидании шины - это талант архитектора программулины,
>которую будет бегать ядро.Кластеры и распределённые вычисления это из вашего мира.
>Ну, а если же есть примеры _более_ эффективаного использования SMP системы ядром,
>
>чем у Линуха - то в студию их, плз :)Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок и конфликтов исчезнут.
>Можно на примерах этих же N-ядерных кластеров, где живут почти лишь только
>пингвины ;)Кластеры и распределённые вычисления вам показались. Меня учили, что распределённые вычисления это когда есть сеть вычислительных машин. Я говорю про одну ВМ с одной ОС.
>>Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде
>>с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди
>>чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но
>>с монолитными ядрами она выпячивается больше.
>А вот с этого места поподробнее, плз ;)
>Каким же это образом принцип размещения кода модулей (в адрессном пространстве ядра
>или в одтельном для каждого модуля) так вот резко и главное
>однозначно(!!) влияет на
>SMP способности ядра? :) (Это если даже забыть, что на эффективность влияет
>и сам пользовательский процесс не меньше ;)"SMP способности ядра".
Да, можно так сказать.
>Проблема SMP - одновременный доступ процессоров по одному адресу. Когда на процесоры
>планируется выполнение кода из разных процессов это не страшно так как
>у каждого процесса свой участок памяти. А когда нити на процессорах
>проходят через один процесс, то...
>Если не понятно, читайте о механизмах синхронизации процессов.
Не нужно считать себя умнее других.
Проблемы SMP систем не государственный секрет. И другие тоже умеют читать,
а может и сделали это уже и давно.
>Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок
>и конфликтов исчезнут.
блин...
так а при чем тут ЯДРО??
Судя по вашим словам его проблемы решаються правильным выбором юзер-левел процессов %))))
>Кластеры и распределённые вычисления вам показались. Меня учили, что распределённые вычисления это
>когда есть сеть вычислительных машин.
а меня учили, что Земля - треугольная.
Есть определение таких вычислений и в нем нет и слова и железной платформе.
Множестом исполнителей может быть как набор нодов кластера, так и ядра SMP системы.>Я говорю про одну ВМ с одной ОС.
Как видишь - неважно. Принципы те же.
>"SMP способности ядра".
>Да, можно так сказать.
что "да"? :) Вопрос был: как принцип защиты памяти модулей может влиять на эффективность работы SMP системы? :) Тем более, что мы выяснили, что эффективность все-таки зависит львиной частью от архитектуры пользовательских процессов.
>>Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок
>>и конфликтов исчезнут.
>блин...
>так а при чем тут ЯДРО??
>Судя по вашим словам его проблемы решаються правильным выбором юзер-левел процессов %))))Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не одним большим куском, а состоящее из небольших, но функционально законченных процессов, способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы блокировок и конфликтов будут более редкими".
>>Кластеры и распределённые вычисления вам показались. Меня учили, что распределённые вычисления это
>Множестом исполнителей может быть как набор нодов кластера, так и ядра SMP
>системы.SMP - архитектура вычислительной системы, а распределённые вычисления подразумевают сеть из слабосвязанных вычислительных машин или мы с тобой по разным учебникам учились. Параллельные вычисления не обязательно распределённые.
>Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не
>одним большим куском, а состоящее из небольших, но функционально законченных процессов,
>способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы
>блокировок и конфликтов будут более редкими".
Уважаемый Белкин, будьте добры перед дальнейшими глубокомысленными теоретизированиями ознакомиться-таки с предметом оных.Если Вы до сих пор полагаете, что линуксовое ядро исполняется одним процессом на одном процессоре, будьте добры, вылазьте из десятилетней как минимум давности. Вот древнее 2.4 на 4-way за вычетом несущественного userspace в основной системе vserver:
init-+-bdflush
[...]
|-keventd
|-kinoded
|-kjournald
|-klogd
|-ksoftirqd_CPU0
|-ksoftirqd_CPU1
|-ksoftirqd_CPU2
|-ksoftirqd_CPU3
|-kswapd
|-kupdated
|-mdrecoveryd
[...]
|-xfsbufd
|-xfsdatad/0
|-xfsdatad/1
|-xfsdatad/2
|-xfsdatad/3
|-xfslogd/0
|-xfslogd/1
|-xfslogd/2
|-xfslogd/3
`-4*[xfssyncd]Калькулятор спонсировать или сами с подсчётами справитесь?
>>Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не
>>одним большим куском, а состоящее из небольших, но функционально законченных процессов,
>>способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы
>>блокировок и конфликтов будут более редкими".
>Уважаемый Белкин, будьте добры перед дальнейшими глубокомысленными теоретизированиями ознакомиться-таки с предметом оных.
>
>
>Если Вы до сих пор полагаете, что линуксовое ядро исполняется одним процессом
>на одном процессоре, будьте добры, вылазьте из десятилетней как минимум давности.
> Вот древнее 2.4 на 4-way за вычетом несущественного userspace в
>основной системе vserver:
>
>init-+-bdflush
>[...]
> |-keventd
> |-kinoded
> |-kjournald
> |-klogd
> |-ksoftirqd_CPU0
> |-ksoftirqd_CPU1
> |-ksoftirqd_CPU2
> |-ksoftirqd_CPU3
> |-kswapd
> |-kupdated
> |-mdrecoveryd
>[...]
> |-xfsbufd
> |-xfsdatad/0
> |-xfsdatad/1
> |-xfsdatad/2
> |-xfsdatad/3
> |-xfslogd/0
> |-xfslogd/1
> |-xfslogd/2
> |-xfslogd/3
> `-4*[xfssyncd]
>
>Калькулятор спонсировать или сами с подсчётами справитесь?
Эх, ма. Смотрите первое сообщение. Критические секции ! Там где запрещён параллельный доступ к внутренним структурам ядра.
>Эх, ма. Смотрите первое сообщение.
Смотрел. Тут Вы вообще про процессы говорили.>Критические секции ! Там где запрещён параллельный
>доступ к внутренним структурам ядра.
Рекомендую:
google://"big kernel lock"+linux
google://"giant kernel lock"+freebsd
по вкусу +history
Отлично ! А я боялся, что так останусь для вас болтуном-идиотом. И теперь переносимся в ОС с микроядром, где количество и размер таких критических секций очень мало так как взаимодействие между частями ОС выполняются на более высоком уровне и есть другие, более подходящие для параллельного выполнения механизмы IPC.
>Отлично ! А я боялся, что так останусь для вас болтуном-идиотом. И
>теперь переносимся в ОС с микроядром, где количество и размер таких
>критических секций очень мало так как взаимодействие между частями ОС выполняются
>на более высоком уровне и есть другие, более подходящие для параллельного
>выполнения механизмы IPC.ты будешь удивлен, но эти "другие, более подходящие для параллельного выполнения механизмы IPC" будут требовать НЕ МЕНЬШЕ локов для обеспечения ТОГО же уровня функционала/гибкости/скорости_реакции_системы/производительности :)
чисто по логике ;)
ну а если логика страдает и ты веришь в эти светлые и непорочные "механизмы IPC" (которыми, кстати, являюццо очередя сообдещий), то смотри.
Если будет одна очередь сообщений не-взирая сколько процов в системе - то будет затык
ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока один работает с очередью (добавляет/удаляет/читает сообщение). Локов мало, но потеряна скорость реакции.
Чтоб поправить ситуацию - делаем, например, 2 очереди сообщений: одна общая, допустим, а другая, допустим, для сетевых операций. И тут уже развязка будет получше: посылка пакета и системный вызов fork() уже могут друг другу не мешать. Но все равно, до оригинальных параметров системы далеко. И мы создаем еще и еще очередя... А на каждую нужен свой лок...
В результате - будет просто микроядро :), но с тем же количеством локов (или большим даже,
ввиду заведомо большего числа процессов в системе).
Так что... как бы твоя гипотеза не доказывала бы обратное ;) Что в микроядре БОЛЬШЕ локов, чем в монолите. (или мы теряем один/больше параметров ядра)
>Если будет одна очередь сообщений не-взирая сколько процов в системе - то
>будет затык
>ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока
>один работает с очередью (добавляет/удаляет/читает сообщение). Локов мало, но потеряна скорость
>реакции.:-) Я знал что вы мне это скажите. Всё это верно, но с небольшой добавочкой... Механизм сообщений обслуживает ядро, а так как оно является самостоятельным процессом и очень маленьким, то оно может просто сидеть (если его жёстко привязать к конкретному процессору) на одном из процессоров и не выгружаясь и не приостанавливаясь на блокировки, быстро выполнять свою работу. Это возможно из-за того, что никто не лезет внутрь ядра боковыми путями, а взаимодействуют через внешний интерфейс. Более того. Это только то, что есть сейчас, а концепция микроядерных ОС позволяет иметь более одного обработчика сообщений или даже более одного ядра в системе, хотя я это ещё нигде не видел и не продумывал сам.
>:-) Я знал что вы мне это скажите. Всё это верно, но
>с небольшой добавочкой... Механизм сообщений обслуживает ядро, а так как оно
>является самостоятельным процессом и очень маленьким, то оно может просто сидеть
>(если его жёстко привязать к конкретному процессору) на одном из процессоров
>и не выгружаясь и не приостанавливаясь на блокировки, быстро выполнять свою
>работу. Это возможно из-за того, что никто не лезет внутрь ядра
>боковыми путями, а взаимодействуют через внешний интерфейс. Более того. Это только
>то, что есть сейчас, а концепция микроядерных ОС позволяет иметь более
>одного обработчика сообщений или даже более одного ядра в системе, хотя
>я это ещё нигде не видел и не продумывал сам.ну шо тебе сказать :)
Хороший ты человек, Белкин, и даже в микроядро веришь (как и я ;)
Но вот то как ты описал работу обработчика очереди сообщений - так не бывает :)
Он не может быть "маленьким" :) Он будет таким как нужно, и должен уметь хранить очень много сообщений в очереди (на всякий случай каких-то затыков в других модулях)
Его _нельзя_ привязывать к одному/двум/не_всем процессорам - будет потеря скорости реакции :) Ну вот если есть простаивающий проц и нужно какому-то модулю поставить сообщение в очередь и никто больше в данный момент подобного делать не хочет (не лочит очередь) - ну неужели ты бы этого не сделал на свободном проце? :)
Лезть "внутрь ядра" конечно же никто не будет и трогать эту очередь "своими грязными модульными руками" - ессьно все будет через интерфейс системных вызовов к этому самому обработчику очереди. Но все равно, хоть ты трижды герой компартии - любая постановка в очередь - это лок этой очереди на небольшое время. Ну и отсюда - все шо я написал ранее.Ну а про "много ядер в системе" - это уже виртуализация. Это тоже может быть, но я тоже пока о таком не слышал :) (тут бы нормальное микроядро с адресной защитой увидеть в жизни, не то что виртуалить его)
> любая постановка в очередь - это лок этой очереди на небольшое время.lockless queues - это отсутствие блокировок при работе с очередями.
>> Если будет одна очередь сообщений не-взирая сколько процов в системе -
>> то будет затык ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока
>> один работает с очередью (добавляет/удаляет/читает сообщение).
>> Локов мало, но потеряна скорость реакции.> :-) Я знал что вы мне это скажите. Всё это верно, но с небольшой добавочкой...
вышеприведенное утверждение очень далеко от действительности.
посмотри например, на патент CA 2536037,
An asynchronous message passing mechanism that allows for multiple messages to be batched for delivery between processes, while allowing for full memory protection during data. transfers and a lockless mechanism for speeding up queue operation and queuing and delivering messages simultaneously.
http://patents1.ic.gc.ca/details?patent_number=2536037
я почему-то совсем не удивляюсь,
что владельцем этого патента является QNX SOFTWARE SYSTEMS.PS какие там могут быть состояния ожидания и взаимные блокировки??? QNX - это RTOS.
PPS ключевые слова "lockless" и "real time" - если твои собеседники не понимают смысла
этих терминов, что-либо доказывать им - это будет практически пустая трата времени и сил.
>An asynchronous message passing mechanism that allows for multiple messages to be
>batched for delivery between processes, while allowing for full memory protection
>during data. transfers and a lockless mechanism for speeding up queue
>operation and queuing and delivering messages simultaneously.
>
>http://patents1.ic.gc.ca/details?patent_number=2536037
Ок, я описывал не оптимальный метод взаимодействия.
Но описанный метод передачи сообщений используеться и в RTLinux'е.
А он - монолит. Суть спора все та же: микроядро ничем не лучше монолита
в управлении SMP системой.
>PS какие там могут быть состояния ожидания и взаимные блокировки??? QNX -
>это RTOS.
ну а тут Вы перегнули. Такого бреда я сказать не мог. "Взаимные блокировки".
Это ж dealdock!
Даже определение для Вас нашел (http://ru.wikipedia.org/wiki/Взаимная_блокировка):
"Взаимная блокировка (англ. deadlock) — ситуация в многозадачной среде, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, захваченных самими этими процессами."
И будьте уверены, что в данном треде не только Вы понимаете значения слов "realtime" и "lockless"...
>Но описанный метод передачи сообщений используеться и в RTLinux'е.
Имееццо ввиду асинхронный метод передачи, не тот что я описал.
> Суть спора все та же: микроядро ничем не лучше монолита в управлении SMP системой.наивный вопрос: почему тогда Cisco купили лиценизю на QNX и делали с нуля новую
систему IOS XR вместо того, чтобы использовать свое собственное монолитное ядро IOS?а что такое "управление SMP системой" ? эфективное использование ресурсов всех CPU ?
SMP kernels плохо масштабируются на количество cores больше восьми, это общеизвестный факт.в системах, где больше 8 cores - используют не SMP Linux kernels, а NUMA Linux kernels.
я не уверен, что QNX будет так же неэффективно использовать cores, как и SMP Linux kernels.> И будьте уверены, что в данном треде
> не только Вы понимаете значения слов "realtime" и "lockless"...я очень надеюсь на это.
>наивный вопрос: почему тогда Cisco купили лиценизю на QNX и делали с
>нуля новую
>систему IOS XR вместо того, чтобы использовать свое собственное монолитное ядро IOS?
Манагеры посчитали сколько будет стоить своя разработка и цену QNX. Выиграли не свои девелоперы всего-то>а что такое "управление SMP системой" ? эфективное использование ресурсов всех CPU
>?
>SMP kernels плохо масштабируются на количество cores больше восьми, это общеизвестный факт.
Расскажи это инженеру этой системы. Чтоб он не SMP, а NUMA делал в таком случае.
Тока непонятно зачем мне это говорить, если ДАНА SMP система. Хорошая или плохая.
И мы ведем речь об управлении ею. Если тебе не нравяццо SMP, а ты любитель NUMA - ну не буду я тебя переубеждать. Но все же призову НЕ путать железо и софт.
Мы сейчас говорим об SMP и ПРОГРАММНЫМИ методами управления. Кому нужны тут твои заключения, что это неудачная аппаратная конфигурация? Какая есть такая есть.
>в системах, где больше 8 cores - используют не SMP Linux kernels,
>а NUMA Linux kernels.
замечательно. У нас разговор об "обычных" SMP на 4 проца.
>я не уверен, что QNX будет так же неэффективно использовать cores, как
>и SMP Linux kernels.
ну так есть же NUMAв Линухе. Ессьно он будет работать на NUMA системах.
Какой идиот туда будет ставить SMP ядро и потом сравнивать это с QNX (кроме QNX манагеров...)?
> инженеру этой системы. Чтоб он не SMP, а NUMA делал в таком случае.
> Тока непонятно зачем мне это говорить, если ДАНА SMP система.посмотри сообщение belkin #19 и свой ответ #21,
SMP очень неэффективна при большом количестве ядер.> И мы ведем речь об управлении ею. Если тебе не нравяццо SMP,
> а ты любитель NUMA - ну не буду я тебя переубеждать.
> Но все же призову НЕ путать железо и софт.AMD Opteron имеет контролер памяти встроенный в процессор, причем каждый
процессор имеет свою собственную память. такая аппаратная конфигурация -это и есть cache coherent NUMA. а уж каким способом ты будешь пытаться
ее использовать, в качестве SMP, или NUMA - железо тебя не ограничивает.>> в системах, где больше 8 cores - используют не SMP Linux kernels, а NUMA Linux kernels.
> замечательно. У нас разговор об "обычных" SMP на 4 проца.уже SMP на четыре? как быстро же ты сдулся... совсем недавно говорил о тысячах процов,
которые успешно шедулит линукс-монолит ядро. пытаешься создать видимость своей правоты?>> я не уверен, что QNX будет так же неэффективно
>> использовать cores, как и SMP Linux kernels.> ну так есть же NUMAв Линухе. Ессьно он будет работать на NUMA системах.
> Какой идиот туда будет ставить SMP ядро и потом сравнивать это с QNXccNUMA - это есть обычная SMP, но с разной скоростью доступа к разным участкам памяти.
кстати, в обычной SMP скорость доступа также не всегда одинаковая из-за сache locality.
>уже SMP на четыре? как быстро же ты сдулся... совсем недавно говорил
>о тысячах процов,
>которые успешно шедулит линукс-монолит ядро. пытаешься создать видимость своей правоты?ладно. Сколько бы ни было процов: суть спора была в том, что принцип защиты памяти ядра (монолит или микроядро) не влияет на качество управления этими процами.
> Сколько бы ни было процов: суть спора была в том, что принцип защиты памяти
> ядра (монолит или микроядро) не влияет на качество управления этими процами.в результате выяснилось, что чем больше cores, тем больше монолитное kernel тратит
времени на синхронизацию доступа к критическим секциям, семафоры, и т.п. фигню.не говоря уже о том, что написать нетривиальное SMP-приложение - это очень сложная задача.
при переходе FreeBSD с 4.х на 6.х - вся 5-я ветка гораздо хуже 4-й и по производительности
и по надежности. такая вот цена одновременного использования нескольких cores системой FreeBSD.не зря ведь откололась DragonFly BSD, потому что Matthew Dillon правильно считал
и считает SMP тупиковой веткой развития мультипроцессорных операционных систем.
2, 4 ядра было вчера, сегодня это уже 4, 8 ядер. через год-два наступит светлое будущее,
и все быстрые сегодня, тормозные и глючные завтра SMP kernels
больше никому не будут нужны при большом количестве cores.и только во фре завершится переход UP => SMP,
как нужно будет начинать новый: SMP => NUMA.
>в результате выяснилось, что чем больше cores, тем больше монолитное kernel тратит
>
>времени на синхронизацию доступа к критическим секциям, семафоры, и т.п. фигню.
нихрена подобного не выяснялось. RTLinux весьма монолит но на любой чих там свой ядреный процесс. То же самое происходит и в микроядре. Вся разница между ними - это ЛИШЬ способ защиты памяти ядра: в монолите один на всех, а в микроядре у каждого потока свое пространство.
>не говоря уже о том, что написать нетривиальное SMP-приложение - это очень
>сложная задача.
>при переходе FreeBSDи только в этом месте стало примерно понятно почему Вы не любите монолит.
Но почему бы не обратить внимание на то, что линух это не ядро BSD?
Там до сих пор наводит страх giantLock.Линух же еще с прошлого мажора весьма культурен в многопроцессорной системе.
Как сказал на днях Михаил о Линуксе и федоре - можно примено также выразиться и о монолите и BSD :)
"Не нужно судить о монолите по BSD ядру" (ц)
>> в результате выяснилось, что чем больше cores, тем больше монолитное kernel тратит
>> времени на синхронизацию доступа к критическим секциям, семафоры, и т.п. фигню.> RTLinux весьма монолит но на любой чих там свой
> ядреный процесс. То же самое происходит и в микроядре.> Вся разница между ними - это ЛИШЬ способ защиты памяти ядра:
> в монолите один на всех, а в микроядре у каждого потока свое пространство.есть и более существенные различия.
.
>> Вся разница между ними - это ЛИШЬ способ защиты памяти ядра:
>> в монолите один на всех, а в микроядре у каждого потока свое пространство.
>
>есть и более существенные различия.это уже следствие того, что все нити не в одном адрессном пространстве.
Там приходиться думать над коммуникациями между ними и т.д. конечно
Но изначальное различие и назначение - это именно разделение всего кода ядра на защищенные
подсистемы.
>уже SMP на четыре? как быстро же ты сдулся... совсем недавно говорил
>о тысячах процов, которые успешно шедулит линукс-монолит ядро.
Мужуки, давайте различать тысячу процессоров под одним экземпляром linux kernel, что успешно бывает, и SMP vs NUMA. Линукс-то от этого микроядерным не становится, и склеивать два _отдельных_ обсуждения в один контекст нисколько не помогает почерпнуть из знаний друг друга.
>Мужуки, давайте различать тысячу процессоров под одним экземпляром linux kernel, что успешно бывает,
Вот об этом и был разговор (как мне казалось). Но назвав тисячепроцессорную систему страшным словом "SMP" - был избит палками :) Да, тут я скорее всего неправ. И такие системы не бывают SMPшными - ну звыняйте, gmm20.
Но в итоге, вроде бы мы вышли на исходную трассу. И спор очерчен заново:
влияет ли архитектура ядра - монолит иль микроядро - на качество управления процами в SMP/NUMA (шоб всякие "по-мелочам" не приставали ;) системах.Причем, что лучше/хуже SMP или NUMA - не рассматриваем.
> И спор очерчен заново: влияет ли архитектура ядра - монолит
> иль микроядро - на качество управления процами в SMP/NUMA системах.операционные системы создаются не для того, чтобы процами управлять,
а чтобы решать прикладные задачи. то что они в результате научились
эффективно "управлять процами" - это всего лишь побочный эффект.мне просто грустно, что там наверху будуть летать многотонные дуры,
которые управляются не QNX`ом. а каким-то монолитным ядром,
пусть даже оно называется и linux с приставкой real-time.
>операционные системы создаются не для того, чтобы процами управлять,
>а чтобы решать прикладные задачи. то что они в результате научились
>эффективно "управлять процами" - это всего лишь побочный эффект.
вай-вай-вай
типа правильно развесить процессы этих самых прикладных задач по процессорам - это не решение прикладных задач.
>мне просто грустно, что там наверху будуть летать многотонные дуры,
>которые управляются не QNX`ом. а каким-то монолитным ядром,
>пусть даже оно называется и linux с приставкой real-time.странно почему тебе не грустно от того, что QNX не так гибок (в лицензировании, доступе к исходникам, разработке под него) как Линух. А летать там будет что нужно и под чем нужно.
А тебя не смущает, что в следствии каких-нить лицензионных (или прочих технических проблем, связанных с тем, что QNX нельзя править) система управления этими самыми "многотонными дурами" будет не столь прозрачна и гибка? Что может кое-где помешать эффективному управлению ними...
Закрытый продукт - это закрытый продукт. Это черный ящик, под который _всегда_ приходиться подстраиваться. Так вот я склонен считать, что пусть инженеры будут затачивать ОС под свои корабли и требования безопасности полетов, а не корабли под ОС и ее недалекие лицензии...
> Мужуки, давайте различать тысячу процессоров
> под одним экземпляром linux kernel, что успешно бывает и SMP vs NUMA.SMP упирается в шину уже после восьми cores. что тут обсуждать?
1 core: UP
2-8 cores: SMP
16-256|512|1024 cores: ccNUMA/NUMAнет тут никакого "SMP vs ccNUMA".
> Линукс-то от этого микроядерным не становится,
> и склеивать два _отдельных_ обсуждения в один контекст
> нисколько не помогает почерпнуть из знаний друг друга.здесь нет двух разных обсуждений. обсуждаются две UNIX-like операционные
системы на определенной аппаратной конфигурации, с количеством ядер 2**n,
где n изменяется от 1 до 10. мнения вижу, факты/аргументы - нет.
обсуждаемые параметры: надежность и скорость работы OS/софта,
простота и удобство написания софта под эту OS, при n => 10.
>SMP упирается в шину уже после восьми cores. что тут обсуждать?
>
>1 core: UP
>2-8 cores: SMP
>16-256|512|1024 cores: ccNUMA/NUMA
>
>нет тут никакого "SMP vs ccNUMA".
у тебя какая-то своя вселенная...
в определении SMP _нет_ ограничений на количесвто процессоров, даже
если на _текущий_ момент технического развития больше 8 процессоров
действительно нецелесообразно объединять в SMP систему.
>> Линукс-то от этого микроядерным не становится,
>> и склеивать два _отдельных_ обсуждения в один контекст
>> нисколько не помогает почерпнуть из знаний друг друга.
>
>здесь нет двух разных обсуждений. обсуждаются две UNIX-like операционные
>системы
какого хрена ты тогда BSD впомнил? Или QNX+Linux+BSD = 2 ???
ты полуторабитный и у тебя переполнение?>на определенной аппаратной конфигурации, с количеством ядер 2**n,
>где n изменяется от 1 до 10. мнения вижу, факты/аргументы - нет.
>
>обсуждаемые параметры: надежность и скорость работы OS/софта,
>простота и удобство написания софта под эту OS, при n => 10."где n изменяется от 1 до 10" ... "при n => 10"
Занавес.
_Nick_> хороша у тя трава :)_Nick_> да тут гении на опеннете пропадают... :)
_Nick_> Ты из какого зоопарка сбежал? :)
_Nick_> у тебя какая-то своя вселенная...
_Nick_> какого хрена ты тогда
_Nick_> ты полуторабитный и у тебя переполнение?
http://www.microchip.ru/phorum/read.php?f=2&i=126600&t=126600
ну наконец-то ты сполз чисто на личности :)
ознаменовав конец спора по теме.
А на оффтопик времени нет
>нет тут никакого "SMP vs ccNUMA".
Э... согласен, спасибо. Но всё равно предлагаю тему остудить, толк уже весь вышел.
>Но всё равно предлагаю тему остудить, толк уже весь вышел.
ну да
уже все
уже корабли и "многотонные дуры" браздят просторы большого опеннета :)
>Эх, ма. Смотрите первое сообщение. Критические секции ! Там где запрещён параллельный
>доступ к внутренним структурам ядра.Ну и ничего страшного.
Это особенность SMP архитектуры.
ГДЕ здесь _вина_ или _неоптимальность_ ядра Линукс?
И особенно в его монолитности :)))
>Это особенность SMP архитектуры.
Нет.
>>Это особенность SMP архитектуры.
>Нет.Ок, много чего было сказано. Может мы о разном.
Я о том, что одна шина SMP системы (и не только SMP) ограничивает возможности процессоров.
Не вижу здесь вины Линуха :) Он вынужден жить в таких условиях.Если же у нас речь о локах, защищающих внутренние структуры от паралельного доступа, - то и тут в линухе все хорошо. Хоть и не имеет это ничего общего с SMP.
>Если же у нас речь о локах, защищающих внутренние структуры от паралельного
>доступа, - то и тут в линухе все хорошо. Хоть и
>не имеет это ничего общего с SMP.
Имеет прямое отношение к возможности работать на SMP в т.ч.
>Имеет прямое отношение к возможности работать на SMP в т.ч.
Ну, разве что учесть то, что проц в SMP должен лочить шину под адресу расположения
лока, для того чтобы с ним работать. Т.е. SMP добавляет просто еще одну блокировку
к сасому факту наличия локов.
Если это прямое отношение - ради бога :)
По мне так это лишь "добавка" от SMP-подсистемы.
>> Смотрите первое сообщение. Критические секции!
>> Там где запрещён параллельный доступ к внутренним структурам ядра.> Ну и ничего страшного.
> Это особенность SMP архитектуры.> ГДЕ здесь _вина_ или _неоптимальность_ ядра Линукс?
> И особенно в его монолитности :)))критические секции для синхронизации - это именно что особенность монолитного ядра.
"особенность SMP архитектуры" состоит в том, что системная шина становится узким местом.
>критические секции для синхронизации - это именно что особенность монолитного ядра.внимательно слушаю сказку о том, что в микроядре (именно том бинаре, который управляет памятью и процессами) нет критических секций :)
>>>Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок
>>>и конфликтов исчезнут.
>>блин...
>>так а при чем тут ЯДРО??
>>Судя по вашим словам его проблемы решаються правильным выбором юзер-левел процессов %))))
>
>Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не
>одним большим куском, а состоящее из небольших, но функционально законченных процессов,
>способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы
>блокировок и конфликтов будут более редкими".
ВНИМАТЕЛЬНО следи за выводом 'ps'а (отгрепаны лишь ядерные нити) на 4-ядерном Линухе.root 2 0.0 0.0 0 0 ? S May15 0:15 [migration/0]
root 3 0.0 0.0 0 0 ? SN May15 0:08 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ? S May15 0:04 [migration/1]
root 5 0.0 0.0 0 0 ? SN May15 0:04 [ksoftirqd/1]
root 6 0.0 0.0 0 0 ? S May15 1:34 [migration/2]
root 7 0.0 0.0 0 0 ? SN May15 0:14 [ksoftirqd/2]
root 8 0.0 0.0 0 0 ? S May15 0:23 [migration/3]
root 9 0.0 0.0 0 0 ? SN May15 0:10 [ksoftirqd/3]
root 10 0.0 0.0 0 0 ? S< May15 0:00 [events/0]
root 11 0.0 0.0 0 0 ? S< May15 0:00 [events/1]
root 12 0.0 0.0 0 0 ? S< May15 0:00 [events/2]
root 13 0.0 0.0 0 0 ? S< May15 0:00 [events/3]
root 218 0.0 0.0 0 0 ? S< May15 0:01 \_ [kblockd/0]
root 219 0.0 0.0 0 0 ? S< May15 0:03 \_ [kblockd/1]
root 220 0.0 0.0 0 0 ? S< May15 0:03 \_ [kblockd/2]
root 221 0.0 0.0 0 0 ? S< May15 0:00 \_ [kblockd/3]
root 339 0.0 0.0 0 0 ? S< May15 0:00 \_ [ata/0]
root 340 0.0 0.0 0 0 ? S< May15 0:00 \_ [ata/1]
root 341 0.0 0.0 0 0 ? S< May15 0:00 \_ [ata/2]
root 342 0.0 0.0 0 0 ? S< May15 0:00 \_ [ata/3]
root 384 0.0 0.0 0 0 ? S< May15 0:00 \_ [aio/0]
root 385 0.0 0.0 0 0 ? S< May15 0:00 \_ [aio/1]
root 386 0.0 0.0 0 0 ? S< May15 0:00 \_ [aio/2]
root 387 0.0 0.0 0 0 ? S< May15 0:00 \_ [aio/3]
root 394 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfslogd/0]
root 395 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfslogd/1]
root 396 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfslogd/2]
root 397 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfslogd/3]
root 398 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfsdatad/0]
root 399 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfsdatad/1]
root 400 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfsdatad/2]
root 401 0.0 0.0 0 0 ? S< May15 0:00 \_ [xfsdatad/3]
root 1200 0.0 0.0 0 0 ? S< May15 0:00 \_ [exec-osm/0]
root 1201 0.0 0.0 0 0 ? S< May15 0:00 \_ [exec-osm/1]
root 1202 0.0 0.0 0 0 ? S< May15 0:00 \_ [exec-osm/2]
root 1203 0.0 0.0 0 0 ? S< May15 0:00 \_ [exec-osm/3]
root 1209 0.0 0.0 0 0 ? S< May15 0:00 \_ [block-osm/0]
root 1210 0.0 0.0 0 0 ? S< May15 0:00 \_ [block-osm/1]
root 1211 0.0 0.0 0 0 ? S< May15 0:00 \_ [block-osm/2]
root 1212 0.0 0.0 0 0 ? S< May15 0:00 \_ [block-osm/3]
root 1230 0.0 0.0 0 0 ? S< May15 0:00 \_ [kcryptd/0]
root 1231 0.0 0.0 0 0 ? S< May15 0:00 \_ [kcryptd/1]
root 1232 0.0 0.0 0 0 ? S< May15 0:00 \_ [kcryptd/2]
root 1233 0.0 0.0 0 0 ? S< May15 0:00 \_ [kcryptd/3]
root 1234 0.0 0.0 0 0 ? S< May15 0:00 \_ [kmpathd/0]
root 1235 0.0 0.0 0 0 ? S< May15 0:00 \_ [kmpathd/1]
root 1236 0.0 0.0 0 0 ? S< May15 0:00 \_ [kmpathd/2]
root 1237 0.0 0.0 0 0 ? S< May15 0:00 \_ [kmpathd/3]Не буду расшифровывать названия всех этих ядерных процессов (и ошибиться боюсь и не охота).
Как видишь МНОГО чего живет именно в отдельной копии для каждого ядра (нити с номером процессора "/N" в конце).
Что же еще не так? :)
>SMP - архитектура вычислительной системы, а распределённые вычисления подразумевают сеть из слабосвязанных
>вычислительных машин или мы с тобой по разным учебникам учились. Параллельные
>вычисления не обязательно распределённые.
http://ru.wikipedia.org/wiki/Распределённые_вычисления"Распределённые вычисления (distributed computing, grid computing, volunteer computing) — способ решения трудоёмких вычислительных задач с привлечением большого числа исполнителей, работающих одновременно над разными частями задачи."
Ну НЕТУ в определении требований к железной части. Просто наличие большого числа исполнителей (процов). Так что и SMP и NUMA - подходят для решения задач используя _метод_ распределенных вычислений.
>Как видишь МНОГО чего живет именно в отдельной копии для каждого ядра
Ядро тут как раз одно, но разложенное по CPU.>Ну НЕТУ в определении требований к железной части. Просто наличие большого числа
>исполнителей (процов). Так что и SMP и NUMA - подходят для
>решения задач используя _метод_ распределенных вычислений.
Не совсем так, для DC SMP/NUMA -- это то, что спрятано внутри нод (исполнителей) и "не касается".
>>Как видишь МНОГО чего живет именно в отдельной копии для каждого ядра
>Ядро тут как раз одно, но разложенное по CPU.
Ессьно, я имел ввиду железное ядро проца здесь.
Витруализации здесь нет - посему линуховое ядро тока одно, конечно же :)
>Тысячи процов ? В тысячах компьютеров - по одному процессору на коробку ?
Не тысячи, а тысячу (на одном ядре) -- из того, что помню.
http://www.novell.com/products/server/techspecs.html (Kernel Limits, искать слово SGI)
http://lkml.org/lkml/2007/3/13/65>Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде
>с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди
>чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но
>с монолитными ядрами она выпячивается больше.
Боюсь, это или системщики такие, или задача такая, или SMP имени Intel с кривым транспортом между камнями. Не знаю, что именно со скедулером, но существенные куски ядра сейчас именно параллелятся (некоторые раскладываются по всем доступным процессорам). Ядра, а не юзерспейсной задачи.Ну и на 2--8 CPU линуксу вообще-то давно хорошо (sweet spot, в смысле, а не "нервно куря"). Чуть ли не с 2.4.
>Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде
>с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди
>чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но
>с монолитными ядрами она выпячивается больше.
Ну во первых SMP системы с количеством процессоров более 4 когда они сидят впринципе не бывает. Так как это и при четырех то процессорах не эффективно. И начинают использовать другие архитектуры. К примеру NUMA, которая присутсвует у AMD за счет чего они в свое время откусили рынок у Intel. И продолжают откусывать там где упор больше идет в ввод-вывод. Так как даже хваленые Intel Core Duo на массированных операциях ввода вывода сливают процессорам от AMD. И это происходит из-за того что работа с переферией у AMD осуществленная более грамотно. У шудлера же Linux недавно находили проблему в том, что после 8 потоков оно масштабируется хреново. Но случай там брался сферический конь в вакууме т.е. все в памяти. Другие же тесты где использовались внешние медленные носители такого резкого обвала не показали.
>У шудлера же Linux недавно находили проблему в том, что после
>8 потоков оно масштабируется хреново. Но случай там брался сферический конь
>в вакууме т.е. все в памяти. Другие же тесты где использовались
>внешние медленные носители такого резкого обвала не показали.Еще бы не показали - ведь это уже тест "медленных носителей", а не того, как работает ПО. А "медленные носители" работают везде почти одинаково ( кроме случаев совсем кривых дров, разумеется ).
И никакой это не сферический конь в вакууме - про in-memory tables слышали?
>Еще бы не показали - ведь это уже тест "медленных носителей", а
>не того, как работает ПО.
Практически все системы работают именно с такими медленными носителями :) И еще долго будут с ними работать.>И никакой это не сферический конь в вакууме - про in-memory tables
>слышали?
Слышал. Приведенная вами штука жрет очень много памяти и имеет довольно специфичную область применения.
>Практически все системы работают именно с такими медленными носителями :) И еще долго
>будут с ними работать.Не спорю. Вот только масштабируемость планировщика потоков нужно тестить под нагрузкой процессоров, а не I/O, как это будет в случае, если задействованы медленные носители. Если на каждом чихе СУБД полезет считывать данные с HDD, то на чем тогда тестировать планировщик? На спящих потоках, что ли?
>Не спорю. Вот только масштабируемость планировщика потоков нужно тестить под нагрузкой процессоров,
>а не I/O, как это будет в случае, если задействованы медленные
>носители. Если на каждом чихе СУБД полезет считывать данные с HDD,
>то на чем тогда тестировать планировщик? На спящих потоках, что ли?
Тестировать надо на реальных задачах. Иначе если к примеру будет произведено тестирование без IO и оптимизация так же будет проведена без IO то может получиться замечательная ситуация, когда у нас будет замечательный шудлер который не особо стыкуется с системой ввода-вывода.
> Начали с покупки технологии RTLinux у FSMLabs.Народ, поясните пожалуйста. Зачем было покупать, если GPL ?
Или это правило хорошего тона, или использована юридическая (техническая) уловка для обхода GPL ??
>> Начали с покупки технологии RTLinux у FSMLabs.
>Народ, поясните пожалуйста. Зачем было покупать, если GPL ?
Так своя технология у них вполне патентованная ( :/ ) и закрытая. Работает не только с линуксом.
писал для qnx6.3
Там только среда разработки и отладки стоит 16 тыс долларов. Это скорее эксклюзив. Удобно, но ограничено.
Писал для linux - верх наслаждения. Emacs и вперед. Лучше и удобнее средства для отладки думаю не существует
>писал для qnx6.3
>Там только среда разработки и отладки стоит 16 тыс долларов. Это скорее
>эксклюзив. Удобно, но ограничено.
>Писал для linux - верх наслаждения. Emacs и вперед. Лучше и удобнее
>средства для отладки думаю не существует$16k для тех, кто строит самолёты, запускает ракеты в космос или строит АЭС это не деньги. Тем более, что в стоимость включено сопровождение высокого уровня и это важнее всего.
>>писал для qnx6.3
>>Там только среда разработки и отладки стоит 16 тыс долларов. Это скорее
>>эксклюзив. Удобно, но ограничено.
>>Писал для linux - верх наслаждения. Emacs и вперед. Лучше и удобнее
>>средства для отладки думаю не существует
>
>$16k для тех, кто строит самолёты, запускает ракеты в космос или строит
>АЭС это не деньги. Тем более, что в стоимость включено сопровождение
>высокого уровня и это важнее всего.16к - "Удобно, но ограничено"
0 - "Лучше и удобнее"а за 16к и под Emacs, думаю, можно поиметь _некислую_ поддержку... ;)
>а за 16к и под Emacs, думаю, можно поиметь _некислую_ поддержку... ;)Уж лучше KDevelop без поддержки, чем emacs с оной ;-)
У меня один знакомый пишет софт для систем наведения подводных лодок.
Используется там QNX. Что такое $16K, если стоимость обычного сдвоенного LCD монитора, после военной приёмки, составляет 500000 руб.(я не опечатался не 50000, а 500000)?? Глупо экономить на мелочах.
Про Linux у них даже думать не хотят.
Потом я не думаю, что RTLinux будет существенно дешевле, а обычный Linux совершенно не подойдёт.P.S.
Для конечного пользователя QNX бесплатен с 2000-го года.
Emacs под QNX отлично работает, как и GCC c binutils.
>Уж лучше KDevelop без поддержки, чем emacs с оной ;-)
+5 %)))))
>У меня один знакомый пишет софт для систем наведения подводных лодок.
>Используется там QNX. Что такое $16K, если стоимость обычного сдвоенного LCD монитора,
>после военной приёмки, составляет 500000 руб.(я не опечатался не 50000, а
>500000)?? Глупо экономить на мелочах.
>Про Linux у них даже думать не хотят.
>Потом я не думаю, что RTLinux будет существенно дешевле, а обычный Linux
>совершенно не подойдёт.
>
>P.S.
>Для конечного пользователя QNX бесплатен с 2000-го года.
Не для конечных, а для одиночного использования. т.е. для себя, в некоммерческих целях.>Emacs под QNX отлично работает, как и GCC c binutils.
это почти как KDE хотеть под венду.
Ну нах#%&^#%&ера извращаццо, когда есть Линух, без идиотских проприетарных ограничений
(сырцы, себя/несебя, коммерческое использование...)?
>У меня один знакомый пишет софт для систем наведения подводных лодок.Вот так ничинаются шпионские скандалы. Молодец, услужил знакомому.
http://kerneltrap.org/node/8414О чём, собственно, тоже говорилось.
>http://kerneltrap.org/node/8414
>
>О чём, собственно, тоже говорилось.Молодец Торвальдс. Не отворачивается от реалий.
А эти самые реалии, собсно уже и так ведуться:
http://kernelnewbies.org/known_regressions
:)))
RTLinuxFree.com is in transition.
Please check back in March for updates.
22 06 2007