LINUX.ORG.RU
ФорумTalks

Аппаратное микроядро. Final discussion

 , ,


4

4

Таки мне удалось формализовать описание расширения системы команд микропроцессора для реализации микроядра L4 на кристалле. Бонусом идёт аппаратный планировщик. Пока речь не идёт об адресных пространствах и об MMU сказано лишь несколько строк. Хотелось бы задать несколько вопросов специалистам по VHDL/Verilog и юристам по патентному праву. Я в правильное место попал?

★★★

Последнее исправление: alman (всего исправлений: 1)

Ответ на: комментарий от GolemXIV

С точки зрения попадания по TLB, большие страницы или сегменты безусловно лучше. (Под сегментом понимается страница, у которой указана длина). Но это налагает ограничение на расположение данных в физической памяти — данные должны лежать в ней непрерывно. И так — для всех программ. Физическая память в таком случае очень быстро закончится, так как «пасьянс» не сойдётся.

Идея микроядра в данном случае проста - авторы ввели понятие корневого менеджера памяти - Sigma0. Изначально эта задача владеет всей доступной физической памятью. Авторы придали задаче sigma0 свойство - только отдавать страницы. Цитата из L4-X2 Refrence Manual:

«Sigma0 is the initial address space. Although it is not part of the kernel, its basic protocol is defined with the kernel. Specific Sigma0 implementations may extend this protocol. The address space Sigma0 is idempotent, i.e., all virtual addresses in this address space are identical to the corresponding physical address. Note that pages requested from Sigma0 continue to be mapped idempotently if the receiver specifies its complete address space as receive fpage. Sigma0 gives pages to the kernel and to arbitrary tasks, but only once. The idea is that all pagers request the memory they need in the startup phase of the system so that afterwards Sigma0 has exhausted all its memory. Further requests will then automatically be denied.»

Таким образом - управление виртуальной памятью делегируется задачам, работающим выше уровня Sigma0. Это свойство корневого менеджера памяти позволяет реализовать его аппаратно. Сейчас не могу это доказать, но пока противоречий не вижу. Что касается сегментации памяти, то в самом худшем случае всё сведётся к обычным страницам, минимально поддерживаемых архитектурой, что приведёт к уменьшению быстродействия, но не остановит работу. Вся забота об оптимальном управлении виртуальной памятью достаётся программисту.

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

Вообще-то я не противник свопа, просто пока не вижу как его организовать на базисе L4. Вместо этого придумываю способы, как бы без него обойтись. Но даже если выгружать «большими страницами», то и в этом способе можно найти некоторое преимущество.

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

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

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

alman ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.