Таненбаум против Торвальдса - часть вторая

> что интересно, mysql так работает: при запуске создается несколько потоков (в 5.0.3 было 4 потока), после чего они засыпают, один из них ждет входящий обращений и на каждый запрос создается поток по его обработке

В прикладной программе такой подход удобен. А вот внутри ядра я бы не стал так поступать.

> Кстати микроядро QNX всего 8К ;) Про скорость работы я тихо умолчу

попадались тесты - работает медленнее линукса 2.4 (и, соотв, 2.6). в QNX во-главу поставлена скорость реакции системы, а не ее производительность

> Если это когда-нибудь произойдет, никакие ядра уже не понадобятся 8). Ядра - это защита памяти. Обсуждаемая статья посвящена живучести ситемы в присуствии ошибок в ее критических компонентах. А если в программе гарантированно нет ошибок - то зачем весь этот оверхэд ?

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

> Если нити в одном адресном пространстве, то, как я уже сказал выше, при использовании Local IPC оверхеда никакого нет.

При IPC - возможно. Но неужели ядро _никак_ не участвует в переключении нитей в рамках одно адресного пространства? "Не верю!" (С) К.Станиславский. Или там user-space threads? Надо покурить доку.

> Да, это интересная и многообещающая идея. Спасибо.

Растет она, кажется, из exokernel'ов

>> А пэйлоад - он будет копироваться между потоками (возможно, разбросанными по разным процессорам, так что как минимум L1-кэш у них разный)? В общем, это же кошмарный сон контроллера кэша 8)

>А это очень интересная особенность L4. Копирование данных между потоками делается средствами L4 во время IPC.

Никакие оптимизации здесь не помогут. Данные, используемые на разных процессорах, должны быть скопированы из кэша одного в кэш другого, и точка. Вот тут то производительность и падает... мордой об асфальт :)

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

Пока не слышал о таких планах ни у Intel, ни у AMD, ни у IBM.

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

>> Пока не слышал о таких планах ни у Intel, ни у AMD, ни у IBM.

а Sun дела даже аппартную Java-машину - PicoJava, и где она?

>Но Линус написал ОС

Он написал ядро

>> Если это когда-нибудь произойдет, никакие ядра уже не понадобятся 8). Ядра - это защита памяти. Обсуждаемая статья посвящена живучести ситемы в присуствии ошибок в ее критических компонентах. А если в программе гарантированно нет ошибок - то зачем весь этот оверхэд ?

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

Я под "ядром" имел в виду "ядро, исполняющееся в защищенном режиме". Проблемы микроядра (производительность) - они из-за того, что используется защита памяти, и ее постоянно надо преодолевать. В отсуствии защиты микроядро - быстрая и удобная штука.

>> Пока не слышал о таких планах ни у Intel, ни у AMD, ни у IBM.

> а Sun дела даже аппартную Java-машину - PicoJava, и где она?

Аппаратная поддержка языка - совсем другая вещь. Там система команд строится специально для поддержки ЯВУ. А для поддержки микроядра нужны, скорее, изменения в управлении виртуальной памятью, что-то типа MMX или VT-x. То есть процессор остается универсальным.

> изменения в управлении виртуальной памятью, что-то типа MMX или VT-x

Хотя, конечно, MMX к управлению виртуальной памятью не относится 8), но идея та же - добавление специальных инструкций.

Монолит работает значительно быстрее в однопроцессорных конфигурациях с однопоточными приложениями.

В случае многопоточности, разница в скорости сокращается.

В случае многопроцессорности или многоядерности железа - микроядра могут оказаться даже быстрее монолитных решений.

alman * (*) (16.05.2006 22:17:15)

[Ответить на это сообщение]

Для этого надо ввести понятие контекста запроса и модифицировать парсер входящих запросов таким образом, чтобы он принимал не только запросы от пользовательских задач, но и ответы от потока, обслуживающий дисковый накопитель. Ещё нам понадобится конечный автомат, который будет анализировать входящие IPC и, в зависимости от источника, выполнять трубуемые действия. Поясню на примере. Запрос read от процесса 3 не нашёл данных в буфере и запросил и их у драйвера винта. После этого снова перешёл в режим ожидания. Следующий запрос пришёл от процесса 5 и данные в буфере обнаружились, они передаются процессу 5 и поток файловой системы снова перешёл в режим ожидания. На этот раз пришёл ответ от винчестера. Мы анализируем контекст и определяем какому пользовательскому процессу предназначены данные. Отдаём данные процессу и снова переходим в режим ожидания. Естественно, я нарочито утрировал роль файловой системы чтобы показать однопоточный метод обработки множественных запросов. Несмотря на то, что операции с файловой системой требуют множество операций, таких как поисх в буферах, анализ inode и проче, в случае если данные находятся в буфере, с точки зрения пользователя запрос будет выполнен мгновенно.

Боюсь, я не очень доходчиво всё объяснил, но главная мысль такая - если система, написанная вами, тормозит, значит проблема не в реализации, а в дизайне.

alman * (*) (17.05.2006 2:23:47)

Для работы в многопроцессорных конфигурациях одно из необходимых условий эффективной работы это кол-во потоков фс = кол-во процессоров, как вы предлагаете обойти эту проблему? И так, кстати, почти на каждое устройство.

> Для работы в многопроцессорных конфигурациях одно из необходимых условий эффективной работы это кол-во потоков фс = кол-во процессоров

Так ли это важно? ФС - это тонкий слой для формирования запроса на ввод/вывод, то же самое и драйвер. Ваше условие необходимо для страничного кэша (не знаю, как это называется в Minix или L4).

Это не важно пока

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

Но если предположить, что драйвер устройства или фс должен выполнить некоторую сложную работу, что справедливо для всех современных фс типа рейзер или xfs, либо, например, для RAID5 или софт dsp и т.п., то сразу возникает проблема узкого горла в виде единственного потока, что по своей сути получается эквивалентно giant lock

> Но если предположить, что драйвер устройства или фс должен выполнить некоторую сложную работу, что справедливо для всех современных фс типа рейзер или xfs, либо, например, для RAID5 или софт dsp и т.п., то сразу возникает проблема узкого горла в виде единственного потока,

Если много сложной работы - тогда конечно, одна нить - это мало.

> что по своей сути получается эквивалентно giant lock

Похоже, но не эквивалентно. Giant lock останавливает все нити которые хотят войти в ядро, IIRC. А здесь все-таки возможна параллельная работа нескольких RAID5, например, или нескольких смонтировнных ReiserFS.

> Для работы в многопроцессорных конфигурациях одно из необходимых условий эффективной работы это кол-во потоков фс = кол-во процессоров, как вы предлагаете обойти эту проблему? И так, кстати, почти на каждое устройство.

Дык это, я не готов сходу назвать решение проблемы. Но уверен, что оно есть.

> > По теме: открытые микроядра - это Mach, Hurd и Minix 3 сейчас, может ещё какие есть ? > Из вышеперечисленного - только Mach микроядро, а остальное - системы на базе микроядра.

И чо - у них ядер совсем нет ( или микроядер ) ? Что же у них тогда ? "микроядро системы Hurd" и "микроядро системы Minix-3" ? Надеюсь, у Вас в голове то, что подобает.

> Но если предположить, что драйвер устройства или фс должен выполнить некоторую сложную работу, что справедливо для всех современных фс типа рейзер или xfs, либо, например, для RAID5 или софт dsp и т.п., то сразу возникает проблема узкого горла в виде единственного потока, что по своей сути получается эквивалентно giant lock

В таком случае имеет смысл разносить по потокам. Но они должны работать не параллельно, а послойно. Т.е. сложные протоколы имеет смысл разбить на слои. При этом параллельность достигнется автоматически.

Ну и буфера надо вынести за пределы потока, чтобы избежать синхронизации доступа к общим данным.

> И чо - у них ядер совсем нет ( или микроядер )? Что же у них тогда ? "микроядро системы Hurd" и "микроядро системы Minix-3" ?

Не знаю что используется в Minix, скорее всего нечто оригинальное.

Hurd использовал микроядро Mach.

Сервер в микроядерной ОС должен готовить преемника на случай своего ухода в core, постоянно сохранять статус. Иначе перезагрузка сервера не будет для клиента прозрачной. Тот же пейджер если рухнет то заберет с собой все информацию о расположении областей памяти, отображениях, правах доступа... Это большой оверхед, при том постоянно, лучше перезагрузить целиком машину при панике монолита, тем более это происходит очень редко.

> Сервер в микроядерной ОС должен готовить преемника на случай своего ухода в core, постоянно сохранять статус. Иначе перезагрузка сервера не будет для клиента прозрачной.

Да особо ничего страшного не произойдёт. Даже если упавший сервер автоматически не рестартует. По крайней мере, если взглюкнёт драйвер USB, то вероятность того, что это потянет за собой разрушение файловой системы - минимальна.

> Тот же пейджер если рухнет то заберет с собой все информацию о расположении областей памяти, отображениях, правах доступа...

Хе-хе. Если пейджер упадёт, то уже ничего не спасёт контроллируемые им процессы. Кстати, в L4 есть возможность назначить свой пейджер для каждого адресного пространства.

> Хе-хе. Если пейджер упадёт, то уже ничего не спасёт контроллируемые им процессы.

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

отвечали на мой пост, не залогинился

>Да особо ничего страшного не произойдёт. Даже если упавший сервер автоматически не рестартует. По крайней мере, если взглюкнёт драйвер USB, то вероятность того, что это потянет за собой разрушение файловой системы - минимальна.

Тогда программировать для микроядра становится забавней чем для монолита. Если в монолите программа убивается мгновенно при крахе ядра, не успев разрушить данные, то в микроядре надо привыкать к тому что подсистемы могут внезапно пропадать и так же появляться, при этом не выполнив запроса и не вернув кода ошибки. Придется следить за таймаутами запросов и повторять снова, думаю таймауты работают плохо на загруженных/медленных машинах.

>Хе-хе. Если пейджер упадёт, то уже ничего не спасёт контроллируемые им процессы. Кстати, в L4 есть возможность назначить свой пейджер для каждого адресного пространства.

Тогда в чем приимущество микроядра, если программы все равно убиваются.

> Тогда в чем приимущество микроядра, если программы все равно убиваются.

В том, что меньший процент сбоев драйверов и ФС вызывает крах системы. Насколько меньший - это вопрос. И еще в том, что пути взаимовлияния компонент ограничены - например, драйвер сетевой платы не может испортить данные блочного устройства или пейджера. То есть - меньше шансов на неправильное поведение. Но оно всё же не исключено совсем.

>В том, что меньший процент сбоев драйверов и ФС вызывает крах системы.

У меня есть программа, работа которой - цель жизни компьютера, это EnemyTerritory :) Программа использует _все_ компоненты системы. Крах любой подсистемы -- невыполненная миссия.

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

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

Микроядро локализует проблему, но не устраняет ее. Более того, из-за увеличивающейся сложности проблем прибавляется.

> У меня есть программа, работа которой - цель жизни компьютера, это EnemyTerritory :) Программа использует _все_ компоненты системы. Крах любой подсистемы -- невыполненная миссия.

Большинство подсистем будет перезапущено после краха, Если сделать это достаточно быстро, ты и не заметишь, Так что - не любой подсистемы.

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

Никто и не говорил, что устраняет. Точнее, никто не говорил, что устраняет _все_ проблемы.

> Более того, из-за увеличивающейся сложности проблем прибавляется.

А каким образом микроядро увеличивает сложность? Оно просто распределяет уже существующую сложность по разным контейнерам.

>А каким образом микроядро увеличивает сложность? Оно просто распределяет уже существующую сложность по разным контейнерам.

Введением дополнительных сущностей, таких как сообщения и механизмы их обмена.

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

Вам нужны визы, таможенный досмотр и ограничение в провозке вещей для поездки в другой город? Это разве не дополнительная сложность?

>>А каким образом микроядро увеличивает сложность? Оно просто распределяет уже существующую сложность по разным контейнерам.

>Введением дополнительных сущностей, таких как сообщения и механизмы их обмена.

Это всего лишь дпугие названия старых сущностей "аргументы процедуры" и "вызов процедуры".

> Вам нужны визы, таможенный досмотр и ограничение в провозке вещей для поездки в другой город? Это разве не дополнительная сложность?

Ну, в аэропортах производят досмотр, и для этого есть веские причины. В общественном транспорте запрещено возить некоторые вещи. А вообще-то аналогии могут далеко завести.

>> А это очень интересная особенность L4. Копирование данных между потоками делается средствами L4 во время IPC.

> Никакие оптимизации здесь не помогут. Данные, используемые на разных процессорах, должны быть скопированы из кэша одного в кэш другого, и точка. Вот тут то производительность и падает... мордой об асфальт :)

Дык. Я не спорю. Но ведь всем системам приходится решать подобнные проблемы. Так что в данном случае при копировании данных между процессорами производительность падает и линукса и фри и виндовс и у микроядрерных система. :)

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

> Пока не слышал о таких планах ни у Intel, ни у AMD, ни у IBM.

Так и нет таких планов, потому что софта нет. Появится софт, пооявятся и заточенные под него микропроцессоры. Я долго удивлялся, когда первый раз увидел на железе лэйбу "Designed for Microsoft Windows XX". Теперь не удивляюсь.

> Тогда в чем приимущество микроядра, если программы все равно убиваются.

Цитирую журнал "Открытые системы" от 02.2006. Статья "От данных к информации". Автор Леонид Черняк.

"Информационные системы достигли предела сложности, и по-прежнему развивать их традиционными методами попросту нерационально. На смену жестко связанным монолитным архитектурам приходят слабо связанные. Они состоят из отедельных независимых модулей, обеспечивающих друг другу те или иные сервисы. Правда, SOA более ресурсоёмка и менее эффективна с точки зрения производительности, но современный уровень быстродействия компьютеров и сетей позволяет смириться с этими издержками".

Моё мнение практически полностью совпадает с автором статьи. Тем более что насчёт ресурсоёмкости можно поспорить. То, что микроядерные архитектуры более ресурсоёмки - это факт, но вот количественное значение явно преувеличено. Кроме того, при правильной организации время отклика системы ничуть не хуже чем у монолитов. Ведь ни для кого не секрет, что быстродействие и латентность - не синонимы.

> Информационные системы достигли предела сложности, и по-прежнему развивать их традиционными методами попросту нерационально.

Ха! Если заменить "информационные" на "операционные", то я это лет 15 назад уже читал. ;)))

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

Ааафигеть! Архитектура "клиент-сервер" снова в деле! :)))

Если серьезно - всё это уже было сказано много раз, опробовано, и решения, доказавшие жизнеспособность - давно в строю. Кстати, ИМХО SOA - это просто RPC на зюмеле, а технологии RPC - лет 20-30.

> Кроме того, при правильной организации время отклика системы ничуть не хуже чем у монолитов.

Но производительность хуже.

> Ведь ни для кого не секрет, что быстродействие и латентность - не синонимы.

Но никто не доказал, что одно исключает другое. Linux с low-latency патчами демонстрировал более высокую пропускную способность,

>> Никакие оптимизации здесь не помогут. Данные, используемые на разных процессорах, должны быть скопированы из кэша одного в кэш другого, и точка. Вот тут то производительность и падает... мордой об асфальт :)

>Дык. Я не спорю. Но ведь всем системам приходится решать подобнные проблемы.

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

> Я просто хочу сказать, что структурирование сетевго стека на набор нитей создает проблему для производительности из-за того, что планировщик будет стараться разнести их по разным процессорам, и накладные расходы на переброску данных между процессорными кэшами съедят производительность, Ну и про переключения контекстов не забудем.

Не всё так плохо, на самом деле. Двухядерные процессоры от Интел используют общий кэш. :)

Да и планировщик позволяет указывать, на каком процессоре должен исполнятся поток.

В объектах синхроизации контекст переключается не намного меньше. А при большом количестве конкурирующих потоков даже больше. Причём, в случае использования мютексов, контекст переключается и планировщиком и в момент защиты объекта от совместного доступа. В случае же послойного исполнения стека, контекст, с наибольшей долей вероятности, переключится после отработки слоя.

Спорить тут бесполезно. Нас может рассудить только практическое сравнение систем, использующих разные подходы.

В любом случае, приятно вести полемику с специалистом. Вряд-ли мы переубедим друг друга, но благодаря спору я узнаю что-то новое.

Стоит дать микроядру фору на аппаратном уровне, т.е. процессор должен быть оптимизирован под микроядерную архитектуру. Включая загрузку самого ядра в память на кристалле.

Iaxx