OSDev

Как я понял...

Есть 32 мегабайт памяти. Есть PDE(каталог таблиц) и PTE(таблица страниц). Есть свой CR3 в каждой задаче процесса. Есть LDT. Есть винчестер на 300ГБ.
Задача: программа не должна знать, что у нас всего 32МБ.
Решение.
C помощью вышеназванных инструментов складывается своя страничная адресация, образуя виртуальное адресное пространство для процесса. Для 4ГБ необходим весь диапазон адресов, имеем (1024*1+1024*1024)*4=PDE(4кБ)+PTE(4MB)=4,004 МБ.
4МБ на каждый процесс. 32/4=8.

Получается 8 процессов с нулевым размером.
Еще думал не создавать максимум таблицу. Тогда имеем PDE(4кБ)+PTE(32кБ)=36кБ.
Допустим, что каждый процесс имеет средний размер 4 кБ. А еще есть LDT, TSS и прочее. Которая в сумме может занять 1кб.
Итого: 36+4+1=41кБ занимает каждый процесс.
Приблизительно получается 700 процессов с учетом ядра, BIOS, VGA memory.
С учетом количества драйверов, служб, программ(а ведь могут занимать больше 4кБ) для микроядерной архитектуры - это катастрофически мало.

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

Как выходить из положения?
Как реализовать эффективную виртуальную память с минимумом потерь?

Аппаратная многозадачность с TSS нафиг не нужна, недаром от неё в 64-разрядном расширении архитектуры официально отказались и поддерживают только в 16- и 32-разрядных защищённых режимах для совместимости. Нафиг не нужна и сегментная организация памяти -- реально она не используется нигде, кроме трюка с регистром FS: для доступа к локальным данным потока (при этом FS: фактически работает не как сегментный регистр, а как базовый -- примерно как в командах типа MOV EAX, disp [EBX], где в роли базового выступает EBX). Таким образом, нафиг не нужны ни TSS (остаётся одна-единственная, поскольку вообще без TSS процессор в защищённом режиме ни к чему не годится), ни LDT, в GDT имеет минимальный размер. А вот от таблиц переадресации никуда не деться, и более эффективного способа организации виртуальной памяти не найти.

Кстати говоря, отвести под задачу все 4 Гбайта не удастся ни под каким соусом, какую-то часть придётся оставить системе (не обязательно 2 Гбайта, как в Винде, но пару-тройку страниц отвести точно придётся, а реально -- больше, чтобы не шибко извращаться в коде системы).

Если не плодить лишние сущности, то 2000 контекстов хватит.

Ты не понял. 4ГБ реально отвести пользовательской программе. Просто все адреса работают с одним и тем же 4кБ блоком. Моя программа начинается с 0 адреса и приближается к 4ГБ пределу, ну при этом мы работаем с одним фиксированным блоком 4кБ в физической памяти.
Я не понимаю зачем отводить дополнительную область для системы.

Вся работа с системой ведется через прерывания. В Minix делается так, в Linux думаю тоже. Как в DOS.
Перед передавать в стек указатель на структуру данных.
Да можна отказаться от LDT, TSS, сегментов. Все делать в ручную. Сохранять регистры в ручную, заполнять дескрипторы тоже вручную через одну и ту же запись в GDT.

Но а как хранить таблицы распределения для каждого процесса?
Неужели для каждого процесса создавать новую 4МБ структуру?

Я пересчитал. Я не домножил на 4байта. На размер дескриптора. А посчитал количество записей за обьем.

Вообщем цифра 700 получается.

Вот теперь пошла настоящая проблема!


С 32МБ Windows 98 справляется спокойно, как и другие nix ОС.


при этом можно поганять в HL2:Episode Two 2007 года.

Я не понимаю как вы могли не столкнуться с этой проблемой? Ведь это ж почти самое главное и самое первое.
Неужели никто не раскажет как он это делает? Или вы до сих пор не создали свою ОС.

Linux и Minix - не одно и то же. Монолит и микроядро соответственно. Даже в микроядре какая-то часть пространства должна быть закреплена за ядром или по крайней мере являться буфером для обмена с ядром. Чем эта часть меньше, тем производительность обычно ниже. В монолите существенная часть пространства отдана ядру, обычно четверть или половина.

Содержимое памяти большинства потоков/процессов частично или полностью может быть выгружено на диск (хотя конечно для учета выгруженых данных тоже нужна память). Чтобы совсем уж не ухудшить производительность и не опуститься до гонки за собственным хвостом, за активными потоками и теми потоками, которые должны их сменять за минимально короткое время, нужно закрепить определенный минимум памяти, даже если не вся память будет сразу отображена в виртуальное адресное пространство. Ядро также должно постоянно находиться в памяти (быть может, за исключением специальных выгружаемых областей). Если опустить глобальные участки ядра используемые конкретным потоком/процессом, а также локальные участки, не используемые для страничного отображения, то минимальное количество страниц, необходимое одному потоку/процессу равно 13 = 4 (2 страницы и 2 таблицы страниц) на код + 4 на данные источника + 4 на данные приемника + 1 на каталог страниц. Если учитывать стек ядра для потока/процесса, то немного больше. Например, я использую для стека ядра 3 конечные страницы (таблицы страниц для глобального участка пространства ядра выделяются сразу и размещаются непрерывно, поэтому я их учитывать не стал, иначе было бы еще по 1 таблице страниц на каждые 1024/4 потока). Итого получается 16. У потоков одного процесса каталог страниц часто общий, поэтому можно считать так: 15 на поток и 1 на процесс. Раз ты спрашиваешь конкретно о том, у кого как реализован учет памяти, то можно уточнять и дальше, однако тут можно целую книгу написать, поэтому лучше отвечать на конкретные вопросы, а не просто рассказывать все подряд.

Как верно подметил phantom-84, ни Windows 98 ни Linux и прочие nix не являются микроядерными. Там тысячи потоков работают в общих процессах.

Я считаю, что плодить изолированные процессы - всё-равно, что плодить бюрократию. И как видно, так считают большинство разработчиков популярных ОС.

Я решил ответить здесь. Так как здесь больше практики.
Когда речь идет о разработке ОС не грех будет брать за эталон разработку под IBM PC настольный компьютер, ОС Linux(она очень много охватывает устройств и платформ).

Отвечаю на общий вопрос
И то и другое. На архитектуре Intel и AMD ты не сможешь добиться защиты на уровне страниц, поэтому отказаться от сегментов невозможно. Сегменты нужны для защиты - защищенный режим ведь!
На примере Linux 2.6.39 там используется одна LDT, TSS из 32 дескрипторов GDT.

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