OSDev

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

_________________
Found a CPU. LAPIC ID: 00

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

Предположим, некая задача вызывает какой-то системный сервис (функцию API системы), например, запустить ввод-вывод, создать событие или ещё что-то в этом роде. Практически на всех архитектурах для этой цели используются инструкции, логически подобные командам INT в IA-32. В результате выполнения такой инструкции происходит прерывание, и управление получает соответствующий обработчик, входящий в состав ядра системы. Само прерывание -- процесс достаточно длительный, поскольку для начала приходится сохранять контекст задачи (потока), и лишь потом заниматься собственно обработкой прерывания. После выполнения действий, связанных с вызванным сервисом, управление вновь возвращается задаче, для чего сначала надо восстановить её контекст (возможно, модифицированный при выполнении сервиса -- например, один из регистров может использоваться для передачи задаче кода завершения сервиса).

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

Если добавить сюда виртуальную память, то накладные расходы в микроядерной ОС могут резко возрасти. В почти всех ОС с ВП ядро занимает одну и ту же часть виртуальных адресов, и отображение их на физическую память одно и то же для любой задачи. Например, в 32-разрядной Windows ядро системы обычно занимает виртуальные адреса от 80000000 до FFFFFFFF. Соответственно, при вызове системного сервиса из задачи менять отображение виртуальных адресов на физические не требуется: ядро системы и так всегда отображено. А вот в микроядерной системе у каждой подсистемы своё собственное виртуальное адресное пространство, поэтому при переходе между ними надо не только контекст процессора сохранять (т.е. содержимое регистров), но ещё переключать и отображение ВП -- а это куда медленнее, поскольку связано со сбросом содержимого TLB и загрузкой туда новых значений.

Я имел в виду именно виртуальную память. Если понимать переключение контекста как сохранение/восстановление состояния, то получится, что любой вызов процедуры - переключения контекста.


Но монолиту тоже придётся загружать в TLB новые значения, адресов ядра там может не оказаться, особенно если приложение интенсивно его использует. Или я что-то не понимаю?

_________________
Found a CPU. LAPIC ID: 00

Насколько я знаю, вся память ядра обычно доступна всем приложениям. В той же винде всё ядро видно отовсюду по одинаковым адресам, которые лежат выше отметки 2 GB. Делается это именно для того, чтобы не перезагрузать TLB по каждому чиху.
А если говорить про х64, то тут уж точно не возникает проблемы "может не быть" с его терабайтами виртуального адресного пространства, которое девать некуда.
Да и на на х32 1-2 ГБ для ядра - за глаза.

Оно может быть вытеснено приложением, которое интенсивно память использует.



Одно дело - сбрасывать TLB всегда, другое дело - заполнять возможно отсутствующие элементы.

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

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



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

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

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

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

Кстати говоря, загрузка в TLB ведётся не ядром, а самим процессором, и только тогда, когда это реально необходимо. К архитектуре ядра это никакого отношения не имеет.

Это я понимаю, но ядро может учитывать стратегию ТЛБ.

Собственно говоря вопрос возник с идеей "вложеных адресных пространств". В первом приближении, на ИА-32 примерно так:
Ядро для "неядерного" программиста выглядит как микроядро, изнутри - монолит, Правильно написанная программа может работать и в нулевом, и в третьем кольце. Соответственно, программы нулевого кольца имеют одно пространство на всех (хотя "не знают" об этом). Что кинуть в нулевое кольцо - решает администратор.
А на "идеальной" архитектуре можно, скажем, 16 вложений.
Даст ли это преимущество перед микроядром??

_________________
Found a CPU. LAPIC ID: 00

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

А стратегию замещения элементов TLB учитывать довольно сложно, поскольку нередко она не является фиксированной и не документируется. Из-за этого, "заложившись" на одну реализацию архитектуры и получив некоторый выигрыш, можно существенно проиграть при другой реализации. В общем, здесь, ИМХО, овчинка выделки не стоит, и надо стремиться просто к уменьшению числа переключений отображения памяти и уменьшению числа используемых страниц. Ну и пользоваться теми документированными возможностями, что прямо заявлены в описании архитектуры (типа глобальных страниц на всех современных процессорах IA-32).