форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Инициатива по устранению глобальных блокировок в L..."

Сообщение от opennews (??) on 17-Май-08, 10:27

Ingo Molnar выступил (http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock) с инициативой создания новой внутренней ветки Linux ядра для постепенного удаления ,больших блокировок (Big Kernel Lock - BKL) в подсистемах ядра и безболезненного перемещения изменений в основную ветку. "<i>Поскольку некоторые уже знают, что в ядре 2.6.26-rc2 удалена поддержка вытесняемой (преептивной) BKL и сделана как spinlock, таким образом превращена снова в невытесняемый (non-preemptible) код. Это изменение возвращает код BKL в состояние которое было в ядре 2.6.7</i>", начал Ingo Molnar. Он отметил, что складывался очень отрицательный эффект на функциях реального времени в ядре, добавляя, что Линус Торвальдс указал, что единственный приемлемый путь продвежения состит в том, чтобы полностью удалить BKL. Инго объяснил: "<i>Эта задача не проста вообще. Спустя 12 лет после того, как Linux стал многопроцессорной ОС, у нас остаётся около 1300 унаследованных частей кода использующих BKL, около 400 l... URL: http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock Новость: http://www.opennet.ru/opennews/art.shtml?num=15922

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

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

Сообщение от vitek (??) on 17-Май-08, 11:03

что радует в линухе - так это эволюционный путь развития ядра. не то, что в винь - одни революции.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от User294 (ok) on 18-Май-08, 02:36
	>что радует в линухе - так это эволюционный путь развития ядра. >не то, что в винь - одни революции. Где вы там революции углядели?Или хотя-бы эволюцию?Ну расскажите чтоли о эволюции NT Kernel с версии 4 до версии 6. От NT4 до Vista. Очень интересно, что же там так уж заметно революционровало или эволюционировало за 10 лет?Основное изменение - теперь в х64 системах подпись драйверов обязательна а изменение ядра запрещено.Чтобы DRM не ломали грузя свои драйвера или меняя ядро (и вообще, MS может отозвав сертификат неугодный драйвер вырубить в любой момент, поквитавшись таким макаром с неугодными, например).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от serg1224 (ok) on 18-Май-08, 03:03
	>>что радует в линухе - так это эволюционный путь развития ядра. >>не то, что в винь - одни революции. > >Где вы там революции углядели? Несовместимость драйверов - вот и вся революция! :-) Зато сколько рабочих мест гарантировано будут загружены долгие годы!!! О людях думают! :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от vitek (??) on 18-Май-08, 06:57
	и углядели, и услышали... Вы чё рекламу не смотрите? виста по идее должна раз так 5-10 быть быстрее NT4. а упомянутый Вами DRM - так этож вообще инновационные нано-технологии.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от vitek (??) on 18-Май-08, 07:04
	да сколько только технологий сменили: winapi16, winapi32, winapi64,.... ole, com, dcom, com+, activex,.... но всё это устарело теперь кроссплатформенный .net уже версии 3 и революционный directx10, который кстати не может работать со старыми драйверами. а Вы говорите - ни каких революций. да их куча и бсе буржуазные.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 17-Май-08, 11:21

мдам BSDишники уже давно ето делают:-).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Erley on 17-Май-08, 12:08
	>мдам BSDишники уже давно ето делают:-). Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом поняли намного раньше, чем в Linux.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от LORanalitic on 17-Май-08, 12:20
	>>мдам BSDишники уже давно ето делают:-). > >Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом >поняли намного раньше, чем в Linux. уже вышел freeBSD 8? ж-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Erley on 17-Май-08, 16:05
	А вы ещё не пробовали 7-ку? Почитайте release notes, самые критичные части ядра очищены от локов, многие драйвера тоже нынче lock-free...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Sergey (??) on 17-Май-08, 12:21
	Чувак, ты эту http://www.opennet.ru/opennews/art.shtml?num=15880 новость читал? >Вообще-то во FreeBSD уже избавились от глобальных блокировок... так что этим там еще и не пахнет, но да, необходимость осознана и люди работают. Так что не вижу никаких причин для тайной гордости ни для бздунов (а у нас начали раньше..), ни для линюксоидов (а нам это не мешало..)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от vitek (??) on 17-Май-08, 13:35
	+1 вот чем только народ не меряется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Аноним (??) on 17-Май-08, 15:55
	Пацан, да ты успокойся, не надо тут пальцы растопыривать. Всем известно (просветись если не слыхал) что во фре работы по устранению GIANT LOCK начались с 5-й версии и более-менее закончены. Это правильно и для фряхи и для линукса, так что всё развивается в правильном направлении.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Sergey (??) on 21-Май-08, 11:34
	>Пацан, да ты успокойся, не надо тут пальцы растопыривать. Гм.. я что-то не углядел раскидывания пальцев, да и беспокойства особого тоже. Хотя вам со стороны виднее.. >Всем известно (просветись если не слыхал) что во фре работы по устранению >GIANT LOCK начались с 5-й версии и более-менее закончены. >Это правильно и для фряхи и для линукса, так что всё развивается >в правильном направлении. Так с этим никто и не спорит, хотя на мой взгляд "работы по устранению ... более-менее закончены" несколько спорно, уверен что и в 8ке будет над чем поработать в этой области. ЗЫ. Еще неплохо бы представляться, а то ходют тут всякие ононимы...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от HFSC (??) on 17-Май-08, 14:54
	>>мдам BSDишники уже давно ето делают:-). > >Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом >поняли намного раньше, чем в Linux. Когда началась эта компания, линукс-пионерия дружно крутила пальцами у висков - "гыгы а нафига?"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от pazke on 17-Май-08, 16:04
	>>>мдам BSDишники уже давно ето делают:-). >> >>Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом >>поняли намного раньше, чем в Linux. > >Когда началась эта компания, линукс-пионерия дружно крутила пальцами у висков - "гыгы >а нафига?" А это ничего что работа по избавлению от BKL в ядре Linux началась с появления spinlock'ов в версии 2.1 ? И кто кстати вам сказал что BSD ядра свободны от giant lock ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от HFSC (??) on 17-Май-08, 19:00
	>[оверквотинг удален] >>> >>>Вообще-то во FreeBSD уже избавились от глобальных блокировок, там необходимость в этом >>>поняли намного раньше, чем в Linux. >> >>Когда началась эта компания, линукс-пионерия дружно крутила пальцами у висков - "гыгы >>а нафига?" > >А это ничего что работа по избавлению от BKL в ядре Linux >началась с появления spinlock'ов в версии 2.1 ? И кто кстати >вам сказал что BSD ядра свободны от giant lock ? 1 Ничего. 2 Никто не сказал ))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от vitek (??) on 18-Май-08, 07:18
	не надо гнать. блокировки в линух круче чем в бзд! а в бзд, чем в соляре. и вообще, настоящая блокировка - это если поставил, то как отрезал.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от smb on 17-Май-08, 16:33

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 17-Май-08, 18:26

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Анонимус on 19-Май-08, 11:53
	>Ключевая фраза - "зависимости блокировок потеряны в тумане 15 лет изменений кода" > > >Херня - кодим дальше, не стоит отвлекаться! Через 15 лет оно само >отремонтируется, если сохранят теперяшние темпы, и  к каждому новому ядру >будут принимать по 30МБ патчей в месяц. +1 Бугога! Спосибо, посмеялсо))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 17-Май-08, 20:08

Слова вроде все знакомые, а смысл ускользает. Pavlinux, признайся, это стёб такой, да?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Ононим on 18-Май-08, 09:14

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от vitek (??) on 18-Май-08, 09:44
	наконец то вменяемый комент
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Осторожный on 18-Май-08, 13:53
	>наконец то вменяемый комент Странно это все FreeBSD начали избавляться от GIANT LOCK еще во времена FreeBSD 5.0 Возможно что к выходу FreeBSD 7.1 практически избавятся. А Linux kernel develop-еры только сейчас разглядели проблему и задумались что неплохо бы что-то сделать с этим. И раньше помниться было много воплей что в Linux SMP развито намного лучше чем в FreeBSD, а  в FreeBSD SMP вообще никакой. А тут выясняется, что все это был наглый обман ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от vitek (??) on 18-Май-08, 14:35
	ну что поделаешь, если линух даже с блокировками так хорошо работает на smp? :-) про top500 опять же можно вспомнить... ЭТО просто работа. что-то приходит новое, что-то уходит навсегда. и это тем более не повод п-и мерятся.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от aZ on 18-Май-08, 16:07
	Лучше? Голые "факты".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от szh (ok) on 19-Май-08, 20:49
	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 %
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от pazke on 19-Май-08, 00:54
	> FreeBSD начали избавляться от GIANT LOCK еще во времена FreeBSD 5.0 Вот задрали пионеры... Борьба с BKL в linux началась еще в ядрах 2.1.x (1996-1998 года). Вопрос: какая версия FreeBSD была в то время и как у нее обстояли дела с SMP ? > И раньше помниться было много воплей что в Linux SMP развито намного лучше чем в FreeBSD, а  в FreeBSD SMP вообще никакой. До 5.0 все было именно так. > А тут выясняется, что все это был наглый обман ... Наконец-то раскрыт всемирный заговор пингвиноводов...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Anonimous on 18-Май-08, 19:33
	>Нелегкую работенку они себе придумали, будь у меня аналогичная ситуация в моем >софте - я бы еще раз 300 подумал прежде чем лезть >в такие дебри. А если бы и полез, то тщательно бы >перестраховывался на каждом шагу. Респект и уважуха ребятам. А они и перестраховались создав новую ветку, если все будет хорохо включат в основною ветку...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Угадай с трх раз on 19-Май-08, 09:04
	Поддержка многопрпоцессорности появилась в третьей версии фряхи, тогда ядро системы работало только на одном процессоре, а процессы на остальных, соответственно при обращении к ядру, процесс на своём процессоре останавливался (или вытеснялся, если было чем вытесняться), если несколько процессоров хотели выполнить системный вызов, то им приходилось ждать, это достаточно неэффективно при большом количестве процессоров (от восьми). Начиная с пятой версии введена поддержка SMP - каждый процесс входит в режим ядра и выполняет системный вызов на своём процессоре, но из-за глобальных блокировок всё-равно приходится ждать, но эффективность всё же выше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от Дмитрий Т on 19-Май-08, 17:37
	Вот тест об удручающей поддержке многопроцессорности во FreeBSD 6 в сравнении с Linux и Solaris http://www.trinity.msk.ru/articles/3 в конце есть ссылка на обсуждение на форуме
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от ElVovan (ok) on 19-Май-08, 21:24
	Да, согласен, это грустно, но система разрабатывается без поддержки таких корпораций, как IBM, RedHat, Novell, и то, что система FreeBSD всё же конкурирует с другими системами (в отличии от hurd или darwin) всё же можно считать серьёзным успехом команды разработчиков. Многоядерные и многопроцессорные системы становятся всё более актуальными и поддержка симметричной многопроцессорности во фряхе с каждым релизом становится всё лучше, в том тесте проверяли шесую версию, хотелось бы чтоб сейчас кто-нибудь протестировал седьмую и грядущую восьмую версии. Соласно описаниям релизов результаты должны заметно отличаться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "OpenNews: Инициатива по устранению глобальных блокировок в L..."

Сообщение от belkin (ok) on 19-Май-08, 12:50

Всё это мура. Унихоиды динозавра нянчют. При таком большом кол-ве тразисторов на кристале вместо нескольких сложных ядер можно сделать сто-двести простых. Выкинуть из процессора всё огромное дерьмо, которое сейчас туда запихивают чтобы он хоть капельку выполнял полезной работы а не тратил всего себя на переключение потоков и дать каждому процессу или даже потоку свой выделенный процессор. Вся хрень планирования с выпихиванием, с конкуренцией между потоками в ОС, с синхронизациями кэша, с проверкой зависимостей по данным и по ресурсам между командами в процессоре, с переименованием регистров, с переключениями, со сложнымы микрокодом и микропрограммным автоматом уходит в попу. И тут выходит на сцену микроядерная ОС с маленькими розовыми ядрышком и процессами-сервисами и всё это замечательно согласуется между собой. И новый виток прогресса и венде капец и Линуху. QNX, Minix.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "OpenNews: Инициатива по устранению глобальных блокировок в L..."
	Сообщение от nik (??) on 19-Май-08, 14:48
	Какая красивая сказка...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "OpenNews: Инициатива по устранению глобальных блокировок в L..."
	Сообщение от pazke on 19-Май-08, 16:31
	Угу. Красивая древняя легенда о пришествии микроядра.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "OpenNews: Инициатива по устранению глобальных блокировок в L..."
	Сообщение от Fireball (??) on 19-Май-08, 21:05
	>И новый виток прогресса и венде >капец и Линуху. QNX, Minix. Это только для спецприменений с большим числом одновременно работающих независимых процессов, которые, однако, требуют не очень большой вычислительной мощности.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "OpenNews: Инициатива по устранению глобальных блокировок в L..."
	Сообщение от belkin (ok) on 20-Май-08, 14:07
	>>И новый виток прогресса и венде >>капец и Линуху. QNX, Minix. > >Это только для спецприменений с большим числом одновременно работающих независимых процессов, которые, >однако, требуют не очень большой вычислительной мощности. Один системный вызов может запустить поток, проходящий через пару десятков процессов. Это сейчас даже в ядре Linux обычное дело.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "OpenNews: Инициатива по устранению глобальных блокировок в L..."
	Сообщение от pavlinux (ok) on 19-Май-08, 21:17
	> ...И тут выходит на сцену микроядерная ОС с маленькими розовыми ядрышком и процессами-сервисами И процессор с 3-мя командам AND OR NOT и XOR на сопроцессре, как мультимедиа дополнение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от ElVovan on 19-Май-08, 13:47

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от pavlinux (ok) on 19-Май-08, 21:27
	КПД по сравнению, с классической многоядерной архитектурой, с кучей дерьма близко к нулю. КПД, по сравнению с классической многоядерной архитектурой, с кучей дерьма близко к нулю. КПД, по сравнению с классической многоядерной архитектурой с кучей дерьма, близко к нулю. КПД по сравнению с классической многоядерной, архитектурой с кучей дерьма, близко к нулю. КПД по сравнению с классической, многоядерной архитектурой, с кучей дерьма, близко к нулю. КПД, по сравнению с классической многоядерной архитектурой, с кучей дерьма, близко к нулю. КПД по сравнению с классической многоядерной архитектурой, с кучей дерьма близко, к нулю. ГДЕ ЗАПЯТУЮ ТО СТАВИТЬ???
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от ElVovan (ok) on 19-Май-08, 21:31
	>ГДЕ ЗАПЯТУЮ ТО СТАВИТЬ??? После КПД и после дерьма. Просто спешил сильно, поэтому отправил не прочитав...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от belkin (ok) on 20-Май-08, 11:39
	>А какая эффективность будет у этой машины? Я использую один процессор - >остальные простаивают. Я что-то в потоке делаю, вычисления какие-то, где каждая >итерация зависит от предыдущей - работает только один процессор, остальные простаивают >при том, что даже работае есть, без синхронизации ресурсов шансов на >будущее такой машины нет. КПД по сравнению с классической многоядерной архитектурой >с кучей дерьма близко к нулю. Эффективность кол-вом одновременно задействованных транзисторов измеряете? Производительность (кол-во операций в секунду) будет зависеть при одинаковых микрокоде и МПА от тактовой частоты. А микропрограммы там будут проще и короче, а значит операции выполяться будут за меньшее кол-во тактов. Т.е. греться при одном активном процессе он будет меньше, но работать быстрее. Вообще-то такая архитектура уже используется, например, в Playstation 3 е.м.н.и.п. .
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от ElVovan _ on 20-Май-08, 12:42
	>Эффективность кол-вом одновременно задействованных транзисторов измеряете? Производительность (кол-во операций в секунду) будет >зависеть при одинаковых микрокоде и МПА от тактовой частоты. А микропрограммы >там будут проще и короче, а значит операции выполяться будут за >меньшее кол-во тактов. Т.е. греться при одном активном процессе он будет >меньше, но работать быстрее. Вообще-то такая архитектура уже используется, например, в >Playstation 3 е.м.н.и.п. . Я про процессоры Cell ничего сказать не могу, по ним не встречал таких мануалов, которые бывают под интеловские процессоры или под арм, но судя по тем обрывкам информации (взятым в основном из рекламы IBM) - это всего лишь очередной виток многоядерности. Где-то когда-то слышал о проекте kilocore - типа тысяча восьмибитных ядер и одно полноценное, чтоб всем этим делом рулить, проект тоже айбиэмовский был, но никаких новостей по этому поводу я уже давно не слышал. Сомневаюсь, что Cell это тот самый kilocore, иначе мы бы на каждом втором банере видели рекламу тысячи ядер. К тому же для управления подобной системой не обязательно нужна микроядерная архитектура - достаточно просто поддержки развитого параллелизма в системе. Что значит микроядерная архитектура? Это ведь не просто разделение ядра на функциональные блоки, сейчас ядро любой операционной системы разделено на отдельные части, занимающиеся своими задачами. Микроядерность - это изоляция адресного пространства каждого такого блока от адресных пространств остальных частей ядра, это может влиять на надёжность системы (блок глюканул, но из-за своей изолированности никакие структуры ядра не испортил, диспетчер его перезапустил, работа продолжается). Соответственно у микроядерных архитектур нет никаких предпосылок к тому, чтоб работать лучше на множестве ядер, в монолитном ядре все процессы ядра таким же образом могут быть раскиданы по процессорам, только работать они будут в общем адресном пространстве.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от belkin (ok) on 20-Май-08, 13:54
	>Что значит микроядерная архитектура? Это ведь не просто разделение ядра на функциональные >блоки, сейчас ядро любой операционной системы разделено на отдельные части, занимающиеся >своими задачами. Микроядерность - это изоляция адресного пространства каждого такого блока >от адресных пространств остальных частей ядра, это может влиять на надёжность >системы (блок глюканул, но из-за своей изолированности никакие структуры ядра не >испортил, диспетчер его перезапустил, работа продолжается). Соответственно у микроядерных архитектур нет >никаких предпосылок к тому, чтоб работать лучше на множестве ядер, в >монолитном ядре все процессы ядра таким же образом могут быть раскиданы >по процессорам, только работать они будут в общем адресном пространстве. У больших ядер есть системные структуры данных, одновременный доступ к которым из модулей невозможен без потери гарантии целостности.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Инициатива по устранению глобальных блокировок в Linux ядре"
	Сообщение от ElVovan (ok) on 20-Май-08, 19:58
	>У больших ядер есть системные структуры данных, одновременный доступ к которым из >модулей невозможен без потери гарантии целостности. Если у разработчиков ОС руки и голова растут откуда надо, то гарантии целостности этих структур сводятся, например, к гарантиям того (это я про одну конкретную самую распространённую архитектуру говорю, на которую пальцем показывать не буду), что инструкция cmpxchg является атомарной и на время своего выполнения блокирует шину данных (предотвращая тем самым доступ к памяти для остальных процессорных ядер). Можно, конечно, долго гадать как эта инструкция работает на суперскалярной архитектуре со внеочередным исполнением инструкций и разложением их на микроинструкции и когда же всё-таки блокируется шина (не при попадании ли этой инструкции на конвейер?), но, тем не менее, она работает именно так, как и должна (несмотря, даже, на многоуровневые раздельные кэши у каждого ядра). В микроядерной архитектуре также стоит вопрос синхронизации данных - все модули ведь общаются между собой. Как они это делают? Сокеты, каналы - не важно - это всего лишь какая-то область памяти; и если один модуль в канал что-то пишет, то другой это читать не может, ну а результат неправильной синхронизации зависит от важности модулей, которые неправильно синхронизировались. Микроядерная архитектура может предотвратить некоторые неудачные проектные решения, типа глобальных блокировок, но при этом увеличивается сложность межмодульных интерфейсов, появляется необходимость в дополнительном копировании данных для передачи их между модулями. Так что микроядро - это не новый виток прогресса, просто альтернативная структура ядра со своими плюсами и минусами, которая, в целом, никак не превосходит монолит, но и не уступает ему. А реально большинство ядер всё же гибридны - там где удобно работает одно большое и толстое ядро, а где оно неудобно - работают отдельные процессы в своих изолированных адресных пространствах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема