Вышла Amiga OS4.0 Classic

что вызвало дикий смех, регистровый байткод? почему?

асилил мыслю. Но само по себе отсутствие MMU и защиты памяти еще ничего не значит про вседозволенность core wars, отрубаем указатели и живем в нормальной managed среде. Вот в L4 выделяется из сигма-0 вполне безопасным способом. Или с нормальным менеджером памяти который все выделяет сам планируя, то есть выдает хендлы и клиент не имеет права на случайный указатель. То есть все ресурсы доступны только по хендлам а указатели не нужны.

>>на Амиге их вообще не нужно было переключать 8)

>ниасилил мыслю

Для начала - что для тебя переключение контекста? 8)

> почему на x86 переключение контекстов -- такая страшная операция, сильно тяжелее переключения userland/kernel стеков

Переключение контекста между нитями (пользовательскими) требует пересечения границы kernel/user и замены значений регистров, не связанных с управлением защитой памяти. Переключение контекста между задачами - это переключение контекста между нитями + переключение контекста защиты памяти. Последнее требует сброса TLB, а это дорогая операция с дорогими последствиями.

Понятно, что при отсуствии разделения ядра/пользователя и защиты памяти (как в Амиге) переключение получается очень быстрым.

> Но само по себе отсутствие MMU и защиты памяти еще ничего не значит про вседозволенность core wars, отрубаем указатели

Каким образом? o_O

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

Что такое "хендл" в данном случае?

>Для начала - что для тебя переключение контекста? 8)

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

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

Если указатели -- например 64-bit GUID, то мы можем их использовать как хендлы без особых опасений что они пересекутся. Выдает хендлы монитор процессов Хоара^W^W^W общесистемный менеджер, он же следит чтобы не выдать на конфликтующий доступ 2 процессов к одному ресурсу.

Этот GUID идет в хеш-таблицу процесса, аналог TLB.

>Переключение контекста между нитями (пользовательскими) требует пересечения границы kernel/user

зачем? нити-то пользовательские? зачем лазить в пользовательские процессы через ядро?

> переключение контекста защиты памяти. Последнее требует сброса TLB,

зачем его переключать? Контекст защиты можно разруливать программно.

>>отрубаем указатели

>Каким образом? o_O

Хотя бы как в L4. Выдаются указатели из сигма-0, у другого процесса указатель бесполезен т.к. не отображен в никуда монитором транзакций/менеджером ресурсов

>>Для начала - что для тебя переключение контекста? 8)

>контекст приложения=множество контекстов функций. Контекст функции = стек данных, глобальные=корень стека, локальные текущей функции = дно стека.

О, йопт o_O Ты не на Эльбрусе системное программирование изучал?

> Если указатели -- например 64-bit GUID, то мы можем их использовать как хендлы без особых опасений что они пересекутся.

Это антинаучная фантастика. Каким образом производится доступ к ресурсам? Ну вот выдали мне хендл на участок памяти - 64-бит GUID, как мне теперь записать туда порцию байтов?

> Этот GUID идет в хеш-таблицу процесса, аналог TLB.

Я правильно понимаю - каждый доступ к памяти через хендл сопровождается lookup'ом в этой хеш-таблице?

>> переключение контекста защиты памяти. Последнее требует сброса TLB,

>зачем его переключать? Контекст защиты можно разруливать программно.

Как и на каких процессорных архитектурах?

>>>отрубаем указатели

>>Каким образом? o_O

> Хотя бы как в L4. Выдаются указатели из сигма-0

То есть выдаются всё же указатели? 8)

> у другого процесса указатель бесполезен т.к. не отображен в никуда

Отображен при помощи MMU, так? То есть имеем работающую защиту памяти со всеми достоинствами и недостатками такого подхода.

>О, йопт o_O Ты не на Эльбрусе системное программирование изучал?

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

> Каким образом производится доступ к ресурсам? Ну вот выдали мне хендл на участок памяти - 64-бит GUID, как мне теперь записать туда порцию байтов?

>Я правильно понимаю - каждый доступ к памяти через хендл сопровождается lookup'ом в этой хеш-таблице?

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

>Как и на каких процессорных архитектурах?

Я правильно понимаю, что программно можно на любых архитектурах? Через тот же монитор ресурсов.

>То есть выдаются всё же указатели? 8)

Ну есть сигма-0 у монитора ресурсов. Он выдает все виртуальные адреса, отображает то что корректно. Левый указатель безопасен, т. к. никуда не отображен MMU.

>Я правильно понимаю - каждый доступ к памяти через хендл сопровождается lookup'ом в этой хеш-таблице?

Я правильно понимаю, что сейчас при трансляции виртуальных адресов в физические мы получаем тот же lookup?

>>О, йопт o_O Ты не на Эльбрусе системное программирование изучал?

>нет, до того что контекст процесса-нитки=стек локальных данных вложенных функций сам додумался

Контекст процесса включает в себя чертову уйму вещей, которые не включает в себя контекст нити. Вообще, это сильно разные контексты (поэтому я стараюсь употреблять слово "контекст" только в значении "контекст MMU").

>> Я правильно понимаю - каждый доступ к памяти через хендл сопровождается lookup'ом в этой хеш-таблице?

> ага, весь вопрос чтобы lookup не вызывал перезагрузку TLB. Потом скешируется в TLB и будет легче.

TLB? Откуда TLB? Без обид, анонимный брат, но ты изобретаешь велосипед с квадратными колесами.

> Я правильно понимаю, что программно можно на любых архитектурах?

Конечно. Есть старая шутка: "Any computer science problem can be solved by introducing another level of indirection", это как раз тот случай. Работать такое решение будет крайне медленно, конечно - это фактически программная эмуляция MMU, и/или это требует managed-языка (как в Сингуларити).

>>Я правильно понимаю - каждый доступ к памяти через хендл сопровождается lookup'ом в этой хеш-таблице?

>Я правильно понимаю, что сейчас при трансляции виртуальных адресов в физические мы получаем тот же lookup?

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

анонимусы жгут!

да.....

А я то дурак, с бодуна, на лор полез...

Тут голову в нормальном состоянии сломать можно....

>Контекст процесса включает в себя чертову уйму вещей, которые не включает в себя контекст нити

Это вложенные контексты, контекст нити вложен в контекст процесса который вложен в контекст ядра.

Вот есть гарвардская архитектура, где разделены памяти команд и данных. И jmp $+next_op не вызывает перезагрузки кеша данных.

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

>TLB? Откуда TLB?

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

Понятно что эти перезагрузки надо минимизировать.

Что если перевернуть ключ и значение? Пусть 64-bit (мало, пусть будет 128-bit) GUID будет "виртуальным адресом" (а был раньше физическим), а сам физ. адрес-значение будет составной, из "внешней части контекста" и внутренней, старого вирт. адреса в контексте процесса.

Ключ в хеш-таблице-типа-TLB будет отдельным GUID чтобы минимизировать коллизии. Перезагрузки лишние устранить, чтобы контекст ядра и охватывающих нитки процессов всегда сидели в таблице.

Сами операции вроде "записать байты по адресу" минимизировать и устранить. Использовать DMA для асинхронной записи по физическим адресам, использовать аналоги map/grant/revoke из L4.

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

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

>конечно - это фактически программная эмуляция MMU

если текущая аппаратная реализация MMU недостаточно эффективна (те же перезагрузки TLB, время переключения избыточно толстого контекста), то 1) может быть программная реализация будет лучше 2) может быть она будет моделью для FPGA ?

>И всё это не просто так сделано аппаратно - это абсолютно критическая по скорости операция.

не помню конкретных цифр, но по порядку величин: AGI, переключение MMX/SSE и т. п. "других аппаратных регистров" было порядка сотни тактов на Pentium III. На PIC'е 16f84 и т.п. в микро-RTOS "контекст нити" занимал байты, и переключение было порядка десятка тактов. (правда это другие частоты и другие такты) Как оно на современных Core Duo/Quad?

>замены значений регистров, не связанных с управлением защитой памяти.

что конкретно кроме cr0?

Читаю все это и страшно становится. Для переключения контекста нужно знание о том что лежит в стеке. Какие-то GUID хрен знает какого размера. Вспоминается i386, где все просто и понятно. Переключение контекста это просто замена всех регистров CPU, как говорят математики необходимо и достаточно, зачем лезть в стек? В чем проблема с указателями тоже неясно, все процессы имеют свое виртуальное адресное пространство, трансляция в физические адреса происходит элементарно и реализована железно. Как можно программно обойти в скорости простейшую операцию реализованную в железе для меня загадка. В любом случае если у вас есть идеи как сделать все лучше и быстрее, то почему бы не подать резюме в intel или amd, вдруг оценят.

>Для переключения контекста нужно знание о том что лежит в стеке.

какое знание? Просто PUSHAD/POPAD +PUSH cr0 итп всякие?

>Переключение контекста это просто замена всех регистров CPU,

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

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

Вот есть процесс А и процесс Б. Указатель 0x10000000 например, куда указывает у А и куда указывает у Б ? Если это общая память, например, внутри ядра или драйвера, то можем запороть ядро некорректным доступом. Получается само по себе число-указатель 0x10000000 еще ничего не значит без знания семантики доступа, то ли это локальная память нитки, то ли процесса, то ли ядра. (те же race conditions).

Получается нужно понимать семантику указателей для корректности доступа (что-то там писал Линус?)

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

> Как можно программно обойти в скорости простейшую операцию реализованную в железе для меня загадка

на каких граничных условиях аппаратная реализация работает неэффективно? вот их и обойти

>>Контекст процесса включает в себя чертову уйму вещей, которые не включает в себя контекст нити

>Это вложенные контексты, контекст нити вложен в контекст процесса который вложен в контекст ядра.

Анонимный брат, твоя терминология малость непривычна 8)

> Вот есть гарвардская архитектура, где разделены памяти команд и данных. И jmp $+next_op не вызывает перезагрузки кеша данных.

Хм... а в фон-Неймановской архитектуре это вызывает перезагрузку кэша данных? 8) Причем здесь вообще гарвард/фон-нейман? :D

>>TLB? Откуда TLB?

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

Уфф,,, так в чем цель? Заместить механизм аппаратной трансляции виртуальных адресов на чисто программный? Или на гибридный? Если первое, то назови свой буфер трансляций как-нибудь по-другому, не TLB, чтобы путаницы не было. Если второе, то почитай о PowerPC, и о том, что думают системные программисты о его механизме трансляции. Если цедь в чем-то другом - опубликуй ее.

> если текущая аппаратная реализация MMU недостаточно эффективна (те же перезагрузки TLB, время переключения избыточно толстого контекста),

Я вот не понял - кто жалуется? И на что жалуется?

> то 1) может быть программная реализация будет лучше

Чем лучше? Скоростью? Смешно. Гибкостью? Наверняка, но зачем эта гибкость? Почитай о PowerPC.

> 2) может быть она будет моделью для FPGA ?

Всё можно засунуть в ПЛИС, конечно. Но снова вопрос - зачем? Что тебе не нравится в текущей схеме трансляции, и как ты собираешься это исправить?

>>И всё это не просто так сделано аппаратно - это абсолютно критическая по скорости операция.

>не помню конкретных цифр, но по порядку величин: AGI, переключение MMX/SSE и т. п. "других аппаратных регистров"

В реплике, на которую ты отвечал, речь шла о трансляции адреса, а не о переключении контекста MMU или контекста нити.

> На PIC'е 16f84 и т.п. в микро-RTOS "контекст нити" занимал байты, и переключение было порядка десятка тактов

Анонимный брат, не употребляй слово "контекст" без указания, к какой сущности оно относится (процесс/MMU, нить, еще что-то).

Amiga DE позже переименовалась в Amiga Anywhere, и разрабатывается до сих пор - www.amiga.com по слухам в этом году мы ещё увидим релиз MorphOS 2.0

улыбнула иконка GoldeED на скриншотах )

>>И jmp $+next_op не вызывает > Хм... а в фон-Неймановской архитектуре это вызывает перезагрузку кэша данных?

Если мы подберем неудобное значение next_op, (шире кэша), то ЕМНИП да. А т.к. в фон-Неймановской код команд и данных идет подряд, то попадаем на перезагрузку, которой могло бы не быть в гарвардской.

> 1) Чем лучше? Скоростью?

аппаратная защита не нужна при хорошо очерченной семантике совместного доступа к данным (тот же managed подход, и/или смартпоинтеры или что навертели с указателями в Cyclone).

Глобально смотря, те же GUIDы в COM-объектах (или возьмём лучше SOM), являются указателями персистентных объектов на уровне системы. Но представления объекта в памяти и "в системе" различаются, и где-то здесь происходит потеря семантики доступа к объектам, необходимо дополнительно возиться чтобы не нарушить семантику.

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

Не думаю что это надо делать статическим планированием, как в VLIW-Эльбрусе , скорее какой-то динамический JIT.

> 2) Что тебе не нравится в текущей схеме трансляции, и как ты собираешься это исправить?

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

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

Даже если заменить CISC опкоды (а лучше VLIW) на какой-то "аппаратный JIT", сжатый байткод, хранить в памяти в сжатом виде, разжимать перед процессором, можно выиграть в полосе пропускания шины процессора, обойтись более узкой полосой для памяти и окупить расходы на сжатие в конечном итоге.

Цель не получить быструю работу процессора или MMU самого по себе, а чтобы вся система в целом (процессор, MMU, ядро ОС, пользовательские треды) работало быстро.

В текущей схеме трансляции адресов не нравятся перезагрузки TLB и схема хэширования, которая приводит к таким простоям, условия при которых это вылазит. Этот контекст защиты, который приводит к перезагрузке.

Значит, либо программная архитектура (ядра ОС+процессов/ниток) должна обходить эти "неудобные" места аппаратного MMU (в пределе в managed среде обойтись без него) либо использовать его другим способом, чтобы перезагрузки возникали как можно реже.

>В реплике, на которую ты отвечал, речь шла о трансляции адреса, а не о переключении контекста MMU или контекста нити.

угу, я опять переключил контекст повествования ))

Просто "контекст нити"-то составной, "переключение контекста" складывается из нескольких компонент, и каждый вносит свой overhead, в худшем случае, так что оценивать нужно все компоненты из которых складываются простои при переключении.

Цель -- придумать такую архитектуру, програмную и аппаратную, которая может быстро переключать контексты. И чтобы она естественно отображалась на то что уже есть.

>Для переключения контекста нужно знание о том что лежит в стеке.

вообще по-моему, достаточно 2-3 стеков для нитки: 1) обычный стек команд, управление, стек вызовов функций 2) стек данных этих самых вложенных контекстов и 3) стек смещений, размеров элементов этих данных

И то третий может не понадобиться.

Получаем что для переключения "контекста нити" надо переключить 3 стека. Откуда и при каких условиях тут появятся перезагрузки TLB?

>Даже если заменить CISC опкоды (а лучше VLIW) на какой-то "аппаратный JIT", сжатый байткод,

это я про вот это: http://en.wikipedia.org/wiki/Von_Neumann_architecture#Von_Neumann_bottleneck

> что вызвало дикий смех, регистровый байткод? почему?

То, что здесь ему оду пропели, а в теме про Parrot - обосрали. :)

дикари-с :)

"Контекст процесса" конечно плохой терминт без указания что в него входит. Вот есть (с) контекст данных процесса, контекст защиты, контекст MMU, контекст MMX/FPU (которые ЕМНИП тоже были конфликтующим ресурсом и переключение вызывало оверхед)

Если конкретно про контекст MMU: ситуация когда процессы грузятся по одному и тому же вирт. адресу приводит к коллизиям хеш-функции в TLB, который ищет по вирт. адресам соотв. физические. Разные контексты защиты приводят к перезагрузке линий в TLB.

С другой стороны, можно выполнять одновременно процессы, которые не приводят к загрузке TLB. Скажем, процесс А грузить по вирт. адресу 0x80000000, а процесс Б по 0x40000000, настроить в MMU размеры доступной памяти для процессов А, Б чтобы куски не пересекались, и указатели "из процесса А" были невалидны в контексте процесса Б.

То есть MMU использовать только в качестве задания допустимой памяти для границ процессов, а грузить их все в одном контексте защиты по разным адресам чтобы минимизировать промахи TLB.

Какие оверхеды на переключение процессов остаются в такой схеме? ( если не учитывать что не любой код перемещаемый? )

Что за бот тут постит , отрубите его нафиек

Ни в коем случае не отрубайте!
Ну где еще увидишь как жабобыдлокодеры ось планируют! Этож флэшмоб мама не горюй! :)

Тэээк - JIT в процессор оне уже звсунули, GUID-handle вместо аддреса замутили ... запасаесмя попкорном - оне сейчас начнут GC к данным в кэше привинчивать 8-о

>>И jmp $+next_op не вызывает > Хм... а в фон-Неймановской архитектуре это вызывает перезагрузку кэша данных?

>Если мы подберем неудобное значение next_op, (шире кэша), то ЕМНИП да.

Не припомню такого, ну да ладно. ИМХО, в этом случае перезагрузится (может быть!) линия i-cache, но не данных.

> Мне не нравится долгое переключение контекстов процессов в типичном монолитном ядре, архитектура процессора, в котором возникает такой оверхед на переключение процессов

Пусть мы тратим 10мкс на переключение контекста (помню, OS/2 на это тратила 100мкс на P100), тогда при 1000 переключений контекста в секунду получаем 10e-6*1e3 == 10e-3 == 1e-2, 1% производительности :D И чтобы не тратить этот процент, предлагается сделать новую архитектуру, писать всё на managed-языках и/или Cyclone, и проверять выход указателей за границы в runtime? А оно точно того стоит? 8)

> Не нравится синхронный характер вычислений когда все делается на основном CPU который крутит такты очень быстро, быстрее чем оперативная память и кеш и вынужден простаивать

И ты собираешься бороться с этой проблемой отказом от кэша (TLB)? o_O

> Цель -- придумать такую архитектуру, програмную и аппаратную, которая может быстро переключать контексты.

Да они уже много лет как придуманы - просто не пользуйся MMU :D

> И чтобы она естественно отображалась на то что уже есть.

А есть мегатонны софта на Си/Си++, ну и как ты его "отобразишь" на архитектуру без аппаратной защиты памяти? Как в DOS? 8)

В общем, примени свою энергию к менее фантастическим проектам.

anonymous (*) (03.12.2007 21:32:07)

> Тэээк - JIT в процессор оне уже звсунули

Справедливости ради, JIT в процессор засунула фирма Интел - то ли в Pentium, то ли в PentiumPro ;)

>> Не нравится синхронный характер вычислений когда все делается на основном CPU который крутит такты очень быстро, быстрее чем оперативная память и кеш и вынужден простаивать

>И ты собираешься бороться с этой проблемой отказом от кэша (TLB)? o_O

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

>Да они уже много лет как придуманы - просто не пользуйся MMU :D

Мы не ищем лёгких путей, не наш метод =) Ты же сам пишешь ниже про мегатонны контента^Wсофта на C/C++. Так что совсем не пользоваться MMU не получится. Не предлагается полностью отрубить защиту памяти, скорее выработать механизмы семантически корректного доступа, при котором точно не будет конфликтов.

> предлагается писать всё на managed-языках и/или Cyclone, и проверять выход указателей за границы в runtime?

не предлагается. Предлагается использовать распределение памяти как в L4: есть ядро, владеет всей памятью, выделяет почти память всю кроме ядерных структур (сигма-0) процессу init. Процесс init запускает подпроцессы, выделяя каждому непересекающиеся блоки памяти. При этом обратиться подпроцес к не своему блоку памяти не может: указатель в другой подпроцесс вызовет GPF. Или не вызовет, если один блок отображен двум процессам (mmap). Далее каждый подпроцесс запускает нити, выставляя корректные записи в MMU (LDT или как там). Нитка залезть в другую нить не может, аналогично.

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

> 1% производительности :D А оно точно того стоит? 8)

ну это конечно померять надо, worst-case, best-case, насколько это все критично, и стоит ли затеваться. Просто интересно стало, какие есть направления совершенствования. И что мешает тем же микроядрам подняться =))

>Справедливости ради, JIT в процессор засунула фирма Интел -

Вроде IBM пыталась делать что-то подобное с памятью, Infini-чего-то там. Типа stacker'а для ОЗУ, только аппаратного

> Предлагается использовать распределение памяти как в L4: есть ядро, владеет всей памятью, выделяет почти память всю кроме ядерных структур (сигма-0) процессу init. Процесс init запускает подпроцессы, выделяя каждому непересекающиеся блоки памяти. При этом обратиться подпроцес к не своему блоку памяти не может: указатель в другой подпроцесс вызовет GPF

Еще раз без обид, но ты, похоже, не понимаешь, как работает MMU.

>> Справедливости ради, JIT в процессор засунула фирма Интел -

> Вроде IBM пыталась делать что-то подобное с памятью, Infini-чего-то там

Я _совсем_ не о том.

>А есть мегатонны софта на Си/Си++, ну и как ты его "отобразишь" на архитектуру без аппаратной защиты памяти? Как в DOS? 8)

В MorphOS, микроядре Quark примерно так и получается: микроядро-как-бы-гипервизор, под нем работают Q-Box с защитой памяти и несколько A-Box без защиты внутри A-Box'а но с защитой A-Box'ов друг от друга. Типа виртуальные машины ДОС, ага.

Но мне больше нравится подход L4.

> Еще раз без обид, но ты, похоже, не понимаешь, как работает MMU.

А чего именно я не понимаю? Если не секрет.

вот в x86 есть виртуальное адресное пространство страниц, которые лежат в записях PTE и кешируются в TLB. В записях PTE записано соответствие вирт. адреса и физического + биты статуса + отображена ли страница. Есть несколько уровней в таблице страниц.

1) то есть, ядро работает с виртуальными адресами, не физическими?

Что происходит при переключении контекста, конкретные записи из PTE/TLB вытесняются записями активного процесса? Поэтому -- переключение -- дорогая операция? Что происходит когда разные процессы отображены по одинаковым вирт. адресам?

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

ps. Да, наверно то что я пытался сформулировать с GUIDами, звучит как "inverted page table", точно.

я понимаю только то, что в амиге есть MMU, но он пользуется только линуксом :)

угу. просто где-то прочитал что в MorphOSи в Quark'e в Q-Box с полной защитой памяти переключение контекстов процессов работает сильно быстрее чем в x86, потому что она работает на PPC. Вот и стало интересно, что это за миф про "дорогое переключение контекстов процессов при полной защите памяти", и что из-за этого микроядра обязательно тормозят. То ли это фирменные грабли x86, то ли неэффективное управление MMU.

> сейчас начнут GC к данным в кэше привинчивать 8-о

не, GC к данным в кеше привинчивать не надо: есть несколько политик GC эффективных в разных случаях для разных применений. Поэтому привинчивать GC, или аллокаторы памяти надо к самому "родительскому процессу"-контейнеру, в котором крутятся рабочие нитки.

А к указателям надо привинчивать семантику. Чтобы по 2 указателям разных процессов было сразу видно, 1) совместимы они или нет по типам 2) разрешен доступ или нет 3) какой характер совместного доступа у параллельных процессов. Если в указатель засунуть 1) мини-тег, класс объекта, на который он ссылается, 2) ссылку на контекст процесса, например, то можно сразу аппаратно посмотреть допустим ли этот указатель в контексте конкретного процесса, а если повозиться с классами с учетом иерархии, можно засунуть и допустимость ссылки на базовый класс вместо ссылки на основной.

И весь доступ вести через "правильные" указатели, а неправильные, бестиповые -- закрыть.

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

Ради ясности. Как, по-моему, должна работать система управления памятью.

Память выделяется не из памяти ядра, а из памяти порождающего процеса. Самый первый процесс порождается ядром (ну или сервером-менеджером ресурсов). То есть, память всегда имеет владельца-процесс, и указатели на эту память всегда учитываются в контексте этого процесса. Указатель на память в другом процессе невалиден, если этот процесс не отображен (mmap) на текущий.

Операции вроде "записать байты по адресу" (ты имел в виду kmemmove или между процессами?) по идее быть не должно. Но если процесс отображен, то указатели допустимы и операция разрешена.

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

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

Ну в общем в духе L4.

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

Ну и чем это отличается от схемы управления памятью в любой нормальной ОС? Что вообще нового в этой схеме? Каким образом это всё эффективнее использует ресурсы вроде TLB или шины "память-кэш"?

Если два процесса грузятся в по одному и тому же вирт. адресу (в контексте процесса), каким записям в TLB соответствуют их страницы? Возникает ли в этом хеше коллизия?

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

> Что вообще нового в этой схеме?

типизированные указатели, со ссылкой на область действия указателя. Менеджер памяти выделяет её из пула и раздает указатели. Указатель на невыделенную память или в другой процесс блокируется MMU (в другой процесс, отображенный mmap'ом -- можно, отображать mmap'ом можно при наличии прав).

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

Становится возможным контролировать семантику совместного доступа из разных процессов (если этот тег также засунуть в указатель). Контролировать выделена память или нет. Контролировать доступ к одному адресу указателями разных типов.

Для старого C/C++ кода по умолчанию указатели автоматически создаются в контексте соотв. процесса и поэтому не могут указывать на другой процесс.

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

> Каким образом это всё эффективнее использует ресурсы вроде TLB

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

Как-то так. Интересно, какие слабые места в этой схеме.

>Каким образом это всё эффективнее использует ресурсы

Это я, тот анонимус. Есть мысли по архитектуре трансляции адресов/управления памятью, но получаются "былинные посты", которые тут наверно не всем интересны. Основаная мысль -- что "долгое переключение контекста MMU" это фирменные грабли x86, и как это можно обойти. Если есть интерес, давай обсудим мылом tweak (эт) pisem дот net , ну или давай своё мыло.