The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Инициатива по устранению глобальных блокировок в Linux ядре

17.05.2008 09:15

Ingo Molnar выступил с инициативой создания новой внутренней ветки Linux ядра для постепенного удаления "больших" блокировок (Big Kernel Lock - BKL) в подсистемах ядра и безболезненного перемещения изменений в основную ветку.

"Поскольку некоторые уже знают, что в ядре 2.6.26-rc2 удалена поддержка вытесняемой (преептивной) BKL и сделана как spinlock, таким образом превращена снова в невытесняемый (non-preemptible) код. Это изменение возвращает код BKL в состояние которое было в ядре 2.6.7", начал Ingo Molnar. Он отметил, что это отрицательно влияет на работу функций реального времени в ядре, добавляя, что Линус Торвальдс указал, что единственный приемлемый путь продвижения состоит в том, чтобы полностью удалить BKL. Инго объяснил:

"Эта задача не проста вообще. Спустя 12 лет после того, как Linux стал многопроцессорной ОС, у нас остаётся около 1300 унаследованных частей кода использующих BKL, около 400 lock_kernel() в критических разделах и около 800 ioctls. Они распространены через довольно трудные области, часто унаследованного кода, который понимают немного людей, и немного людей смеют касаться. Включая ведущих людей, таких как Алан Кoкс, чтобы отобразить семантику и удалить код BKL, и даже для Алана это - длинная и трудная задача."

Ingo продолжал описывать, как работает BKL, как отличается от других механизмов блокировки, и почему это надолго усложнит удаление из ядра. Он отметил, что различные зависимости блокировок потеряны в тумане 15 лет изменений кода, "все это внушило своего рода Страх, Неопределенность и Сомнения относительно BKL: никто действительно не знает этого, никто действительно не смеет касаться этого, и код может сломаться тихо и изящно, если блокировка BKL использована неправильно."

Он тогда предложил "изменить правила игры", создавая "kill-the-BKL" ветку ядра, в которой "превращает BKL в обычный, хотя несколько большой mutex, с изворотливыми блокировками/разблокировками, интерфейс названный lock_kernel () и'unlock_kernel ().".

Ingo отметил, что новое дерево уже раскрыло серьезный регресс в ядре, и продолжил: "Как только это дерево стабилизируется, устранение BKL может быть сделано обычным и хорошо известным способом устранения больших блокировок: Спускаясь ниже, в подсистему и заменяя это блокировкой самой подсистемы, затем разделяя те блокировки и устраняя их. Мы делали это бесчисленное число раз в прошлом и есть много способных разработчиков, которые могут приняться за решение таких проблем."

Линус положительно ответил, "Ok, я безусловно рад. Это именно те вещи, которые я хотел бы видеть." Он предложил, производить усовершенствования в новой "kill-the-BKL" ветке так, чтобы облегчить перемещение очевидных исправлений, позволяя дополнительно тестировать уже в основной ветви ядра.

  1. Главная ссылка к новости (http://kerneltrap.org/Linux/Re...)
Автор новости: pavlinux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/15922-linux
Ключевые слова: linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, vitek (??), 11:03, 17/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    что радует в линухе - так это эволюционный путь развития ядра.
    не то, что в винь - одни революции.
     
     
  • 2.23, User294 (ok), 02:36, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >что радует в линухе - так это эволюционный путь развития ядра.
    >не то, что в винь - одни революции.

    Где вы там революции углядели?Или хотя-бы эволюцию?Ну расскажите чтоли о эволюции NT Kernel с версии 4 до версии 6. От NT4 до Vista. Очень интересно, что же там так уж заметно революционровало или эволюционировало за 10 лет?Основное изменение - теперь в х64 системах подпись драйверов обязательна а изменение ядра запрещено.Чтобы DRM не ломали грузя свои драйвера или меняя ядро (и вообще, MS может отозвав сертификат неугодный драйвер вырубить в любой момент, поквитавшись таким макаром с неугодными, например).

     
     
  • 3.24, serg1224 (ok), 03:03, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>что радует в линухе - так это эволюционный путь развития ядра.
    >>не то, что в винь - одни революции.
    >
    >Где вы там революции углядели?

    Несовместимость драйверов - вот и вся революция! :-)
    Зато сколько рабочих мест гарантировано будут загружены долгие годы!!! О людях думают! :-)

     
  • 3.25, vitek (??), 06:57, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    и углядели, и услышали...
    Вы чё рекламу не смотрите?
    виста по идее должна раз так 5-10 быть быстрее NT4.
    а упомянутый Вами DRM - так этож вообще инновационные нано-технологии.
     
  • 3.26, vitek (??), 07:04, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    да сколько только технологий сменили:
    winapi16, winapi32, winapi64,....
    ole, com, dcom, com+, activex,....
    но всё это устарело
    теперь кроссплатформенный .net уже версии 3
    и революционный directx10, который кстати не может работать со старыми драйверами.

    а Вы говорите - ни каких революций.
    да их куча и бсе буржуазные.

     

  • 1.4, Аноним (4), 11:21, 17/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    мдам BSDишники уже давно ето делают:-).
     
     
  • 2.5, Erley (?), 12:08, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >мдам BSDишники уже давно ето делают:-).

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

     
     
  • 3.6, LORanalitic (?), 12:20, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>мдам BSDишники уже давно ето делают:-).
    >
    >Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом
    >поняли намного раньше, чем в Linux.

    уже вышел freeBSD 8? ж-)

     
     
  • 4.17, Erley (?), 16:05, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А вы ещё не пробовали 7-ку? Почитайте release notes, самые критичные части ядра очищены от локов, многие драйвера тоже нынче lock-free...
     
  • 3.7, Sergey (??), 12:21, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Чувак, ты эту http://www.opennet.dev/opennews/art.shtml?num=15880 новость читал?
    >Вообще-то во FreeBSD уже избавились от глобальных блокировок...

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

     
     
  • 4.10, vitek (??), 13:35, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    +1
    вот чем только народ не меряется.
     
  • 4.15, Аноним (4), 15:55, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Пацан, да ты успокойся, не надо тут пальцы растопыривать.
    Всем известно (просветись если не слыхал) что во фре работы по устранению GIANT LOCK начались с 5-й версии и более-менее закончены.
    Это правильно и для фряхи и для линукса, так что всё развивается в правильном направлении.
     
     
  • 5.56, Sergey (??), 11:34, 21/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Пацан, да ты успокойся, не надо тут пальцы растопыривать.

    Гм.. я что-то не углядел раскидывания пальцев, да и беспокойства особого тоже. Хотя вам со стороны виднее..
    >Всем известно (просветись если не слыхал) что во фре работы по устранению
    >GIANT LOCK начались с 5-й версии и более-менее закончены.
    >Это правильно и для фряхи и для линукса, так что всё развивается
    >в правильном направлении.

    Так с этим никто и не спорит, хотя на мой взгляд "работы по устранению ... более-менее закончены" несколько спорно, уверен что и в 8ке будет над чем поработать в этой области.
    ЗЫ. Еще неплохо бы представляться, а то ходют тут всякие ононимы...

     
  • 3.12, HFSC (??), 14:54, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>мдам BSDишники уже давно ето делают:-).
    >
    >Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом
    >поняли намного раньше, чем в Linux.

    Когда началась эта компания, линукс-пионерия дружно крутила пальцами у висков - "гыгы а нафига?"

     
     
  • 4.16, pazke (?), 16:04, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>>мдам BSDишники уже давно ето делают:-).
    >>
    >>Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом
    >>поняли намного раньше, чем в Linux.
    >
    >Когда началась эта компания, линукс-пионерия дружно крутила пальцами у висков - "гыгы
    >а нафига?"

    А это ничего что работа по избавлению от BKL в ядре Linux началась с появления spinlock'ов в версии 2.1 ? И кто кстати вам сказал что BSD ядра свободны от giant lock ?

     
     
  • 5.20, HFSC (??), 19:00, 17/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>>
    >>>Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом
    >>>поняли намного раньше, чем в Linux.
    >>
    >>Когда началась эта компания, линукс-пионерия дружно крутила пальцами у висков - "гыгы
    >>а нафига?"
    >
    >А это ничего что работа по избавлению от BKL в ядре Linux
    >началась с появления spinlock'ов в версии 2.1 ? И кто кстати
    >вам сказал что BSD ядра свободны от giant lock ?

    1 Ничего.
    2 Никто не сказал ))

     
  • 3.27, vitek (??), 07:18, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    не надо гнать.
    блокировки в линух круче чем в бзд!
    а в бзд, чем в соляре.

    и вообще, настоящая блокировка - это если поставил, то как отрезал.

     

  • 1.18, smb (?), 16:33, 17/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для спорщиков про фряху - читать http://wiki.freebsd.org/SMPTODO

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

     
  • 1.19, Аноним (19), 18:26, 17/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ключевая фраза - "зависимости блокировок потеряны в тумане 15 лет изменений кода"

    Херня - кодим дальше, не стоит отвлекаться! Через 15 лет оно само отремонтируется, если сохранят теперяшние темпы, и  к каждому новому ядру будут принимать по 30МБ патчей в месяц.

     
     
  • 2.39, Анонимус (?), 11:53, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Ключевая фраза - "зависимости блокировок потеряны в тумане 15 лет изменений кода"
    >
    >
    >Херня - кодим дальше, не стоит отвлекаться! Через 15 лет оно само
    >отремонтируется, если сохранят теперяшние темпы, и  к каждому новому ядру
    >будут принимать по 30МБ патчей в месяц.

    +1

    Бугога! Спосибо, посмеялсо))

     

  • 1.22, Аноним (4), 20:08, 17/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Слова вроде все знакомые, а смысл ускользает. Pavlinux, признайся, это стёб такой, да?
     
  • 1.28, Ононим (?), 09:14, 18/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нелегкую работенку они себе придумали, будь у меня аналогичная ситуация в моем софте - я бы еще раз 300 подумал прежде чем лезть в такие дебри. А если бы и полез, то тщательно бы перестраховывался на каждом шагу. Респект и уважуха ребятам.
     
     
  • 2.29, vitek (??), 09:44, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    наконец то вменяемый комент
     
     
  • 3.31, Осторожный (?), 13:53, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >наконец то вменяемый комент

    Странно это все
    FreeBSD начали избавляться от GIANT LOCK еще во времена FreeBSD 5.0
    Возможно что к выходу FreeBSD 7.1 практически избавятся.
    А Linux kernel develop-еры только сейчас разглядели проблему и задумались что неплохо бы что-то сделать с этим.

    И раньше помниться было много воплей что в Linux SMP развито намного лучше чем в FreeBSD, а  в FreeBSD SMP вообще никакой.
    А тут выясняется, что все это был наглый обман ...

     
     
  • 4.32, vitek (??), 14:35, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ну что поделаешь, если линух даже с блокировками так хорошо работает на smp? :-)
    про top500 опять же можно вспомнить...

    ЭТО просто работа.
    что-то приходит новое, что-то уходит навсегда.

    и это тем более не повод п-и мерятся.

     
     
  • 5.33, aZ (?), 16:07, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше? Голые "факты".
     
     
  • 6.45, szh (ok), 20:49, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.top500.org/stats/list/30/osfam
    Ноябрь 2007

    Linux   426   85.20 %  
    Windows 6 1.20 %
    Unix 30 6.00 %
    BSD Based 2 0.40 %
    Mixed 34 6.80 %
    Mac OS 2 0.40 %

     
  • 4.37, pazke (?), 00:54, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > FreeBSD начали избавляться от GIANT LOCK еще во времена FreeBSD 5.0

    Вот задрали пионеры... Борьба с BKL в linux началась еще в ядрах 2.1.x (1996-1998 года).
    Вопрос: какая версия FreeBSD была в то время и как у нее обстояли дела с SMP ?

    > И раньше помниться было много воплей что в Linux SMP развито намного лучше чем в FreeBSD, а  в FreeBSD SMP вообще никакой.

    До 5.0 все было именно так.

    > А тут выясняется, что все это был наглый обман ...

    Наконец-то раскрыт всемирный заговор пингвиноводов...

     
  • 2.35, Anonimous (?), 19:33, 18/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Нелегкую работенку они себе придумали, будь у меня аналогичная ситуация в моем
    >софте - я бы еще раз 300 подумал прежде чем лезть
    >в такие дебри. А если бы и полез, то тщательно бы
    >перестраховывался на каждом шагу. Респект и уважуха ребятам.

    А они и перестраховались создав новую ветку, если все будет хорохо включат в основною ветку...


     
     
  • 3.38, Угадай с трх раз (?), 09:04, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержка многопрпоцессорности появилась в третьей версии фряхи, тогда ядро системы работало только на одном процессоре, а процессы на остальных, соответственно при обращении к ядру, процесс на своём процессоре останавливался (или вытеснялся, если было чем вытесняться), если несколько процессоров хотели выполнить системный вызов, то им приходилось ждать, это достаточно неэффективно при большом количестве процессоров (от восьми). Начиная с пятой версии введена поддержка SMP - каждый процесс входит в режим ядра и выполняет системный вызов на своём процессоре, но из-за глобальных блокировок всё-равно приходится ждать, но эффективность всё же выше.
     
     
  • 4.44, Дмитрий Т (?), 17:37, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Вот тест об удручающей поддержке многопроцессорности во FreeBSD 6 в сравнении с Linux и Solaris
    http://www.trinity.msk.ru/articles/3
    в конце есть ссылка на обсуждение на форуме
     
     
  • 5.48, ElVovan (ok), 21:24, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да, согласен, это грустно, но система разрабатывается без поддержки таких корпораций, как IBM, RedHat, Novell, и то, что система FreeBSD всё же конкурирует с другими системами (в отличии от hurd или darwin) всё же можно считать серьёзным успехом команды разработчиков. Многоядерные и многопроцессорные системы становятся всё более актуальными и поддержка симметричной многопроцессорности во фряхе с каждым релизом становится всё лучше, в том тесте проверяли шесую версию, хотелось бы чтоб сейчас кто-нибудь протестировал седьмую и грядущую восьмую версии. Соласно описаниям релизов результаты должны заметно отличаться.
     

  • 1.40, belkin (ok), 12:50, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё это мура. Унихоиды динозавра нянчют. При таком большом кол-ве тразисторов на кристале вместо нескольких сложных ядер можно сделать сто-двести простых. Выкинуть из процессора всё огромное дерьмо, которое сейчас туда запихивают чтобы он хоть капельку выполнял полезной работы а не тратил всего себя на переключение потоков и дать каждому процессу или даже потоку свой выделенный процессор. Вся хрень планирования с выпихиванием, с конкуренцией между потоками в ОС, с синхронизациями кэша, с проверкой зависимостей по данным и по ресурсам между командами в процессоре, с переименованием регистров, с переключениями, со сложнымы микрокодом и микропрограммным автоматом уходит в попу. И тут выходит на сцену микроядерная ОС с маленькими розовыми ядрышком и процессами-сервисами и всё это замечательно согласуется между собой. И новый виток прогресса и венде капец и Линуху. QNX, Minix.
     
     
  • 2.42, nik (??), 14:48, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Какая красивая сказка...
     
     
  • 3.43, pazke (?), 16:31, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Красивая древняя легенда о пришествии микроядра.
     
  • 2.46, Fireball (??), 21:05, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >И новый виток прогресса и венде
    >капец и Линуху. QNX, Minix.

    Это только для спецприменений с большим числом одновременно работающих независимых процессов, которые, однако, требуют не очень большой вычислительной мощности.

     
     
  • 3.54, belkin (ok), 14:07, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>И новый виток прогресса и венде
    >>капец и Линуху. QNX, Minix.
    >
    >Это только для спецприменений с большим числом одновременно работающих независимых процессов, которые,
    >однако, требуют не очень большой вычислительной мощности.

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


     
  • 2.47, pavlinux (ok), 21:17, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > ...И тут выходит на сцену микроядерная ОС с маленькими розовыми ядрышком и процессами-сервисами

    И процессор с 3-мя командам AND OR NOT и XOR на сопроцессре, как мультимедиа дополнение.

     

  • 1.41, ElVovan (?), 13:47, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А какая эффективность будет у этой машины? Я использую один процессор - остальные простаивают. Я что-то в потоке делаю, вычисления какие-то, где каждая итерация зависит от предыдущей - работает только один процессор, остальные простаивают при том, что даже работае есть, без синхронизации ресурсов шансов на будущее такой машины нет. КПД по сравнению с классической многоядерной архитектурой с кучей дерьма близко к нулю.
     
     
  • 2.49, pavlinux (ok), 21:27, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/

    КПД по сравнению, с классической многоядерной архитектурой, с кучей дерьма близко к нулю.
    КПД, по сравнению с классической многоядерной архитектурой, с кучей дерьма близко к нулю.
    КПД, по сравнению с классической многоядерной архитектурой с кучей дерьма, близко к нулю.
    КПД по сравнению с классической многоядерной, архитектурой с кучей дерьма, близко к нулю.
    КПД по сравнению с классической, многоядерной архитектурой, с кучей дерьма, близко к нулю.
    КПД, по сравнению с классической многоядерной архитектурой, с кучей дерьма, близко к нулю.
    КПД по сравнению с классической многоядерной архитектурой, с кучей дерьма близко, к нулю.


    ГДЕ ЗАПЯТУЮ ТО СТАВИТЬ???

     
     
  • 3.50, ElVovan (ok), 21:31, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ГДЕ ЗАПЯТУЮ ТО СТАВИТЬ???

    После КПД и после дерьма. Просто спешил сильно, поэтому отправил не прочитав...

     
  • 2.51, belkin (ok), 11:39, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А какая эффективность будет у этой машины? Я использую один процессор -
    >остальные простаивают. Я что-то в потоке делаю, вычисления какие-то, где каждая
    >итерация зависит от предыдущей - работает только один процессор, остальные простаивают
    >при том, что даже работае есть, без синхронизации ресурсов шансов на
    >будущее такой машины нет. КПД по сравнению с классической многоядерной архитектурой
    >с кучей дерьма близко к нулю.

    Эффективность кол-вом одновременно задействованных транзисторов измеряете? Производительность (кол-во операций в секунду) будет зависеть при одинаковых микрокоде и МПА от тактовой частоты. А микропрограммы там будут проще и короче, а значит операции выполяться будут за меньшее кол-во тактов. Т.е. греться при одном активном процессе он будет меньше, но работать быстрее. Вообще-то такая архитектура уже используется, например, в Playstation 3 е.м.н.и.п. .

     
     
  • 3.52, ElVovan _ (?), 12:42, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >Эффективность кол-вом одновременно задействованных транзисторов измеряете? Производительность (кол-во операций в секунду) будет
    >зависеть при одинаковых микрокоде и МПА от тактовой частоты. А микропрограммы
    >там будут проще и короче, а значит операции выполяться будут за
    >меньшее кол-во тактов. Т.е. греться при одном активном процессе он будет
    >меньше, но работать быстрее. Вообще-то такая архитектура уже используется, например, в
    >Playstation 3 е.м.н.и.п. .

    Я про процессоры Cell ничего сказать не могу, по ним не встречал таких мануалов, которые бывают под интеловские процессоры или под арм, но судя по тем обрывкам информации (взятым в основном из рекламы IBM) - это всего лишь очередной виток многоядерности. Где-то когда-то слышал о проекте kilocore - типа тысяча восьмибитных ядер и одно полноценное, чтоб всем этим делом рулить, проект тоже айбиэмовский был, но никаких новостей по этому поводу я уже давно не слышал. Сомневаюсь, что Cell это тот самый kilocore, иначе мы бы на каждом втором банере видели рекламу тысячи ядер.
    К тому же для управления подобной системой не обязательно нужна микроядерная архитектура - достаточно просто поддержки развитого параллелизма в системе.
    Что значит микроядерная архитектура? Это ведь не просто разделение ядра на функциональные блоки, сейчас ядро любой операционной системы разделено на отдельные части, занимающиеся своими задачами. Микроядерность - это изоляция адресного пространства каждого такого блока от адресных пространств остальных частей ядра, это может влиять на надёжность системы (блок глюканул, но из-за своей изолированности никакие структуры ядра не испортил, диспетчер его перезапустил, работа продолжается). Соответственно у микроядерных архитектур нет никаких предпосылок к тому, чтоб работать лучше на множестве ядер, в монолитном ядре все процессы ядра таким же образом могут быть раскиданы по процессорам, только работать они будут в общем адресном пространстве.

     
     
  • 4.53, belkin (ok), 13:54, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Что значит микроядерная архитектура? Это ведь не просто разделение ядра на функциональные
    >блоки, сейчас ядро любой операционной системы разделено на отдельные части, занимающиеся
    >своими задачами. Микроядерность - это изоляция адресного пространства каждого такого блока
    >от адресных пространств остальных частей ядра, это может влиять на надёжность
    >системы (блок глюканул, но из-за своей изолированности никакие структуры ядра не
    >испортил, диспетчер его перезапустил, работа продолжается). Соответственно у микроядерных архитектур нет
    >никаких предпосылок к тому, чтоб работать лучше на множестве ядер, в
    >монолитном ядре все процессы ядра таким же образом могут быть раскиданы
    >по процессорам, только работать они будут в общем адресном пространстве.

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

     
     
  • 5.55, ElVovan (ok), 19:58, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >У больших ядер есть системные структуры данных, одновременный доступ к которым из
    >модулей невозможен без потери гарантии целостности.

    Если у разработчиков ОС руки и голова растут откуда надо, то гарантии целостности этих структур сводятся, например, к гарантиям того (это я про одну конкретную самую распространённую архитектуру говорю, на которую пальцем показывать не буду), что инструкция cmpxchg является атомарной и на время своего выполнения блокирует шину данных (предотвращая тем самым доступ к памяти для остальных процессорных ядер). Можно, конечно, долго гадать как эта инструкция работает на суперскалярной архитектуре со внеочередным исполнением инструкций и разложением их на микроинструкции и когда же всё-таки блокируется шина (не при попадании ли этой инструкции на конвейер?), но, тем не менее, она работает именно так, как и должна (несмотря, даже, на многоуровневые раздельные кэши у каждого ядра).
    В микроядерной архитектуре также стоит вопрос синхронизации данных - все модули ведь общаются между собой. Как они это делают? Сокеты, каналы - не важно - это всего лишь какая-то область памяти; и если один модуль в канал что-то пишет, то другой это читать не может, ну а результат неправильной синхронизации зависит от важности модулей, которые неправильно синхронизировались.
    Микроядерная архитектура может предотвратить некоторые неудачные проектные решения, типа глобальных блокировок, но при этом увеличивается сложность межмодульных интерфейсов, появляется необходимость в дополнительном копировании данных для передачи их между модулями.
    Так что микроядро - это не новый виток прогресса, просто альтернативная структура ядра со своими плюсами и минусами, которая, в целом, никак не превосходит монолит, но и не уступает ему.
    А реально большинство ядер всё же гибридны - там где удобно работает одно большое и толстое ядро, а где оно неудобно - работают отдельные процессы в своих изолированных адресных пространствах.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру