Насколько эффективна гипотетическая ОС в едином адресном пространстве?

Question

[Семён Приходько]

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

Comments

[CityCat4]

Мысль навеяна разбором Metldown/Spectre? :)

[Семён Приходько]

CityCat4, Нет

Answer 1

[Алексей Черемисин]

Да, будут эффективными, но без сохранения контекста и восстановления никуда не деться. Код приложений будет реентерабельный, защита же все равно будет через MMU. А без защиты - любое приложение или ошибка, положит всю систему.
Более того, такие ОС есть. Например OS-9 https://ru.m.wikipedia.org/wiki/OS-9
Чего лишимся? Будет гораздо труднее делать swap, так как у нас не будет транслятора памяти, и нельзя будет сохранить дамп процесса и на это место подгрузить дамп другого процесса.

Comments

[Семён Приходько]

Спасибо. А есть ли где-то сравнительные бенчмарки для OS-9, чтобы понять, о каком порядке величин выигрыша идёт речь?

[Семён Приходько]

Например, сравнение среднего числа тактов на системный вызов Linux с таковым для OS-9? Или сравнение одних и тех же программ с интенсивным IO (раз OS-9 UNIX-подобная). Последний вид бенчмарка был бы особенно интересен.

[Алексей Черемисин]

Семён Приходько, увы, прямые бенчмарки делать было бессмысленно. Эта ОС из класса RTOS, там многие подсистемы работают совсем не так, как в линуксе. Но по системным вызовам все примерно одинаково, также через TRAP-прерывания реализуется, также примерно в mmu таблицы устроены. Да, немного медленнее, так как в os-9 разделены уровни микроядра и драйверов, но это особенность самой операционки, тоже через пресловутый mmu.
Здесь же проблема все равно останется, кеши при переключении контекстов защиты все равно останутся.

[jcmvbkbc]

защита же все равно будет через MMU.

Что-то не срастается защита через MMU и "системные вызовы не будут отличаться от вызова обычных (виртуальных) функций", потому что если код и данные ядра защищены MMU, то системный вызов должен отличаться от вызова функции, как минимум чтобы повысить привилегии.

[Алексей Черемисин]

jcmvbkbc, да, здесь вы правы, повышение привелегий возможно только через прерывание на нужный уровень. Я хотел сказать, что на современном этапе без mmu защищенную систему не построить, или она от DOS/windows chicago ничем не будет отличаться. Другой вопрос, что ядро может защищать через mmu неаллокированные участки памяти, при этом этом трансляцию можно и не делать, а изменять только нужные участки.
Например в той же os-9 при переключении контекста процесса обновляется только таблица доступа к куче процесса и страницам аллокированной памяти, плюс для исполняемого кода ставится биты на чтение и исполнение.
Другими словами, ядро разрешает всем читать и исполнять код из страниц, куда загружены исполняемые коды, а для данных процесса постоянно изменяет защиту с каждым переключением планировщика. Если процесс пытается обратиться не туда, происходит NMI с решением, кому и куда отдать управление и что предпринять. Память в системе вся прямая, никакой трансляции нет, ну или почти нет :-).

[jcmvbkbc]

Я хотел сказать, что на современном этапе без mmu защищенную систему не построить

Ну почему же? Например, если пользовательские приложения -- это байткод, для которого интерпретатор/JIT гарантирует правильность обращений к памяти. Фантом, например, так сделан.

Другой вопрос, что ядро может защищать через mmu неаллокированные участки памяти, при этом этом трансляцию можно и не делать

Если в системе есть полный MMU (а не MPU, который трансляцию делать не умеет), то с точки зрения производительности я не вижу причин ограничиваться только защитой и не использовать трансляцию.

[Алексей Черемисин]

Даже в байткоде я бы не сильно расчитывал на полную гарантию, а уж тем более, если говорим про JIT. Пример к последним уязвимостям на javascript с чтением из кеша тому подтверждение. Тем более компиляция в нативный код.
Использовать или нет трансляцию, зависит от организации кода и данных, если код компилируется полностью перемещаемым (реентерабельным), то трансляция не очень то и нужна по факту, ведь в этом случае коду все равно по каким адресам его расположили. А трансляция может быть использована для других целей, например объединить несколько областей памяти в одну, или подменить адреса flash на ram.

Answer 2

[jcmvbkbc]

Однако переключения контекста при вытесняющем планировании, а также порождённые ими инвалидации кэша никуда не денутся.

Но VIPT/PIPT кэш не нужно инвалидировать при переключении контекста, а VIVT, мне кажется, уже давно никто не делает.