OSDev http://osdev.su/ |
|
4ГБ виртуальное адресное пространство http://osdev.su/viewtopic.php?f=6&t=420 |
Страница 1 из 1 |
Автор: | JSON [ 28 май 2011, 20:12 ] |
Заголовок сообщения: | 4ГБ виртуальное адресное пространство |
Как я понял... Есть 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!? Потому что это единственный способ, который я знаю, узнать, когда процесс делает обращение к конкретному блоку памяти и обработать исключение дозагрузив с хард диска в память нужный кусок. Как выходить из положения? Как реализовать эффективную виртуальную память с минимумом потерь? |
Автор: | SII [ 28 май 2011, 20:41 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
Аппаратная многозадачность с TSS нафиг не нужна, недаром от неё в 64-разрядном расширении архитектуры официально отказались и поддерживают только в 16- и 32-разрядных защищённых режимах для совместимости. Нафиг не нужна и сегментная организация памяти -- реально она не используется нигде, кроме трюка с регистром FS: для доступа к локальным данным потока (при этом FS: фактически работает не как сегментный регистр, а как базовый -- примерно как в командах типа MOV EAX, disp [EBX], где в роли базового выступает EBX). Таким образом, нафиг не нужны ни TSS (остаётся одна-единственная, поскольку вообще без TSS процессор в защищённом режиме ни к чему не годится), ни LDT, в GDT имеет минимальный размер. А вот от таблиц переадресации никуда не деться, и более эффективного способа организации виртуальной памяти не найти. Кстати говоря, отвести под задачу все 4 Гбайта не удастся ни под каким соусом, какую-то часть придётся оставить системе (не обязательно 2 Гбайта, как в Винде, но пару-тройку страниц отвести точно придётся, а реально -- больше, чтобы не шибко извращаться в коде системы). |
Автор: | Himik [ 28 май 2011, 21:13 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
Если не плодить лишние сущности, то 2000 контекстов хватит. |
Автор: | JSON [ 28 май 2011, 21:17 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
SII писал(а): Кстати говоря, отвести под задачу все 4 Гбайта не удастся ни под каким соусом, какую-то часть придётся оставить системе (не обязательно 2 Гбайта, как в Винде, но пару-тройку страниц отвести точно придётся, а реально -- больше, чтобы не шибко извращаться в коде системы). Ты не понял. 4ГБ реально отвести пользовательской программе. Просто все адреса работают с одним и тем же 4кБ блоком. Моя программа начинается с 0 адреса и приближается к 4ГБ пределу, ну при этом мы работаем с одним фиксированным блоком 4кБ в физической памяти. Я не понимаю зачем отводить дополнительную область для системы. Вся работа с системой ведется через прерывания. В Minix делается так, в Linux думаю тоже. Как в DOS. Перед Код: int 31h передавать в стек указатель на структуру данных.Да можна отказаться от LDT, TSS, сегментов. Все делать в ручную. Сохранять регистры в ручную, заполнять дескрипторы тоже вручную через одну и ту же запись в GDT. Но а как хранить таблицы распределения для каждого процесса? Неужели для каждого процесса создавать новую 4МБ структуру? |
Автор: | JSON [ 28 май 2011, 21:49 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
Himik писал(а): Если не плодить лишние сущности, то 2000 контекстов хватит. Я пересчитал. Я не домножил на 4байта. На размер дескриптора. А посчитал количество записей за обьем. Вообщем цифра 700 получается. Вот теперь пошла настоящая проблема! С 32МБ Windows 98 справляется спокойно, как и другие nix ОС. Цитата: Системные требования для Windows 98: процессор 486DX/66 MHz или лучше, 16 Мб ОЗУ и по крайней мере 195 Мб свободного дискового пространства при стандартной установке. при этом можно поганять в HL2:Episode Two 2007 года. Я не понимаю как вы могли не столкнуться с этой проблемой? Ведь это ж почти самое главное и самое первое. Неужели никто не раскажет как он это делает? Или вы до сих пор не создали свою ОС. |
Автор: | phantom-84 [ 29 май 2011, 01:15 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
Linux и Minix - не одно и то же. Монолит и микроядро соответственно. Даже в микроядре какая-то часть пространства должна быть закреплена за ядром или по крайней мере являться буфером для обмена с ядром. Чем эта часть меньше, тем производительность обычно ниже. В монолите существенная часть пространства отдана ядру, обычно четверть или половина. Содержимое памяти большинства потоков/процессов частично или полностью может быть выгружено на диск (хотя конечно для учета выгруженых данных тоже нужна память). Чтобы совсем уж не ухудшить производительность и не опуститься до гонки за собственным хвостом, за активными потоками и теми потоками, которые должны их сменять за минимально короткое время, нужно закрепить определенный минимум памяти, даже если не вся память будет сразу отображена в виртуальное адресное пространство. Ядро также должно постоянно находиться в памяти (быть может, за исключением специальных выгружаемых областей). Если опустить глобальные участки ядра используемые конкретным потоком/процессом, а также локальные участки, не используемые для страничного отображения, то минимальное количество страниц, необходимое одному потоку/процессу равно 13 = 4 (2 страницы и 2 таблицы страниц) на код + 4 на данные источника + 4 на данные приемника + 1 на каталог страниц. Если учитывать стек ядра для потока/процесса, то немного больше. Например, я использую для стека ядра 3 конечные страницы (таблицы страниц для глобального участка пространства ядра выделяются сразу и размещаются непрерывно, поэтому я их учитывать не стал, иначе было бы еще по 1 таблице страниц на каждые 1024/4 потока). Итого получается 16. У потоков одного процесса каталог страниц часто общий, поэтому можно считать так: 15 на поток и 1 на процесс. Раз ты спрашиваешь конкретно о том, у кого как реализован учет памяти, то можно уточнять и дальше, однако тут можно целую книгу написать, поэтому лучше отвечать на конкретные вопросы, а не просто рассказывать все подряд. |
Автор: | Himik [ 29 май 2011, 01:55 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
StasBaybak писал(а): С 32МБ Windows 98 справляется спокойно, как и другие nix ОС. Как верно подметил phantom-84, ни Windows 98 ни Linux и прочие nix не являются микроядерными. Там тысячи потоков работают в общих процессах. Я считаю, что плодить изолированные процессы - всё-равно, что плодить бюрократию. И как видно, так считают большинство разработчиков популярных ОС. |
Автор: | JSON [ 29 май 2011, 22:01 ] |
Заголовок сообщения: | Re: 4ГБ виртуальное адресное пространство |
Я решил ответить здесь. Так как здесь больше практики. Когда речь идет о разработке ОС не грех будет брать за эталон разработку под IBM PC настольный компьютер, ОС Linux(она очень много охватывает устройств и платформ). Отвечаю на общий вопрос Цитата: Сегменты или страницы? И то и другое. На архитектуре Intel и AMD ты не сможешь добиться защиты на уровне страниц, поэтому отказаться от сегментов невозможно. Сегменты нужны для защиты - защищенный режим ведь! На примере Linux 2.6.39 там используется одна LDT, TSS из 32 дескрипторов GDT. Глупая дискусия, на мой взгляд. И то и другое нужно. Сводить к минимуму использования дескрипторов сегментов - вот и все. Учти Таненбаум предлагает свою ОС, также идеологию микроядра там где требуется высокая надежность и защищенность. Где необходима отказоустойчивость. Все зависит от желаемого результата. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |