Несколько вопросов начинающего

SII
+1
[add] к тому же при возможности работы со страницами большего объема можно динамически переходить на них. Это сэкономит пару страниц (не более 1024=4Мб на задачу).

 

Я не спорю, я могу создать таблицу первого уровня всего из двух элементов, но мало ли что будет дальше идти в памяти. Вот обратится программа к следующей страничке, а под этим элементом вдруг окажется что в бите P (Present) стоит 1 (ну мусор какой был) и будет не предсказуемое. Я не уверен что если я ничего с памятью не делал, то обязательно она будет иметь значение 0 (вся подчищенная). Да и тем более, мне обязательно нужно чтобы последние индексы (1023, 1022, 1021...) были задействованы, так как там будет ядро операционной системы. А если мне они нужны, то получится что обязательно нужно делать и промежуточные элементы (например, 00000000000000000000000000000000b). Ведь как выбирается элемент:

Для каждой задачи (программы) у меня будет свой каталог страниц (таблица каталога таблиц и таблицы страниц). Если они будут создаваться при запуске программы, то это ещё ладно. Но ведь по размеру они занимают более 4 МБ, и для каждой задачи хранить такой объём - это катастрофа.

Не могу же я просто составить такую таблицу:

Мне обязательно нужно будет вставлять все недостающие элементы (например, в виде 00000000000000000000000000000000b):

Вот и получается что в момент запуска задачи (программы), формируются таблицы (таблица первого уровня, таблицы второго уровня). Но они обязаны же занимать около 4 МБ, как иначе-то?!

 

Люди, вот я тупанул! Вы мне хотите сказать что я обязан делать в таблице первого уровня (таблица каталога таблиц) все 1024 элемента, но не обязан составлять для каждого элемента таблицу второго уровня (таблица страниц) если у элемента таблицы первого уровня (таблица каталога таблиц) у бита P (Present) стоит значение 0. Так что ли?

 

То есть могу для каждой задачи составлять:

Всё равно как-то смущает меня то, что для каждой задачи нужно ещё что-то хранить.

 

да точно.
ни кто не мешает сделать так

Код (Text):

1. catalog dd prog_table0, prog_table1, 1020 dup (0), sys_4Mb_page0, sys_4Mb_page1 ; это 4 Кб
2. prog_table0 dd prog_page0,1022 dup (0),prog_page1; это еще 4 Кб
3. prog_table1 dd prog_page2,511 dup (0),prog_page3, 511 dup (0); это еще 4 Кб

страницы ядря системы могут быть общими для всех процессов поэтому без их объема для такой программы понадобится 12 Кб на каталог страниц и 16 Кб на страницы программы (ну и 8 Мб общих для всех программ системных данных/кода)
то есть виртуальное пространство будет дырявым. более того одна физическая страница может повторятся по несколько раз в одном и том же виртуальном пространстве и в разных виртуальных пространствах.
а многоуровневые таблицы для экономии памяти и ввели как раз.

 

Всем доброго утра!

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

И с использованием свободных битов при значении 0 в бите P (Present) стало понятно. Однако тут есть один нюанс - хранить в них информацию необходимо только после того, как уже было обращение к этой страничке. Приведу пример для понимания того, как я понимаю эту ситуацию. Пускай мы запустили программу которая требует 2 странички для кода и 2 странички для данных (под знаками ? подразумевается какой-то адрес):

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

И следом:

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

И когда обратится программа к страничке, которая не в оперативной памяти, то сразу будет ясно откуда брать данные.

Какой из вариантов лучше использовать?

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

А то если с каждой задачей столько хранить - не так уж и много задач запустишь))) Есть вариант хранить на жёстком диске, но уж не знаю на сколько он хорош (всё таки оперативную память для чего-то использовать нужно - не просто так её придумали).

Жду ваших советов!

 

Ещё хотел спросить про стек. Является ли необходимым делать для программы отдельно странички с кодом, данными и стеком? Или же можно ограничиться только лишь страничками с кодом и данными?

Просто чтобы программа пользователя сама определяла указатель регистра ESP на смещение в сегменте SS (которым будет всё адресное пространство, хотя можно ограничить чтобы в ядро операционной системы не сувался - однако если даже сунется, то пользователь не сможет работать со страничками супервизора и произойдёт исключение). Хотя с другой стороны растёт в обратном направлении...в общем не знаю как лучше делать.

По крайней мере знаю точно - отделение между собой кода, данных и стека должно соответствовать выравниванию в размере странички (в моём случае в 4 КБ).

 

А посмотрите для интереса, сколько ОЗУ сжирает под себя Винда. Конечно, её делали индусские быдлокодеры, но объём всё ж не совсем из пальца высосан. И вообще, сколько раз говорить -- читайте литературу, там всё это описано (лично я принципиально такие вещи не объясняю -- не люблю лентяев и халявщиков).

Плоховато знаете, значит. Страничному механизму глубоко плевать, к коду происходит обращение, к данным или к стеку -- он даже словей таких не знает, ему знакомы лишь линейные адреса и физические. Ну и таблицы страниц, естественно. Так что ничто не мешает и код, и данные, и стек расположить на одной странице (а 4 килобайт для хелловорлда более чем достаточно). И вообще, выравнивания требует только стек, и то, насколько помню, в соответствии с разрядностью режима (на границу 2 байтов в реальном режиме и 16-разрядном защищённом, 4 байтов -- в 32-разрядных режимах, 8 байтов -- в 64-разрядном). Опять-таки -- читать надо больше, а флудить -- меньше.

 

s3dworld
Что касается #366 поста скажу следующее. У меня на компьютере пропускная способность оперативной памяти достигает 31 Гбит/сек (в среднем ок 28, но там какие-то фирменные навороты подстегивают еще чуть чуть), это почти 8 Гбайт/сек. При этом жесткий диск может только читать со скоростью 100 Мб/сек (почувствуй разницу). Если будете увлекаться файлом подкачки, то напишите отстой. Файл подкачки это вообще должна быть надстройка над механизмом распределения памяти, использующаяся тогда и только тогда, когда это самой памяти не хватает. В идеале файла подкачки в системе просто быть не должно. Разберитесь сначала с механизмом распределения присутствующей памяти между задачами, а потом уже заморачивайтесь с файлом подкачки страниц.
Что касается #367 поста, то тут SII прав. Страничный механизм это лишь механизм преобразования адресов памяти и ему глубоко наплевать где эти адреса задействованы. А стек - что такое стек. Вспомню курс ассемблера. Стек это область данных оперативной памяти адресуемая через пару ss:sp(esp,rsp) и набор команд для работы с этими данными.

[add]

А вот этого делать нив коем случае нельзя. Просто вы рискуете терять страницы если будете бесконтрольно подставлять свободные под каждую прихоть прикладной программы. Вообще поймите. Писать операционную систему можно тогда и только тогда когда четко понимаешь что хочешь получить. Операционная система должна жестко ограничивать свободу прикладной программы и также жестко разграничивать все эти программы относительно друг друга. По хорошему прикладная программа должна думать, что она одна и все принадлежит ей и не подозревать, что вместе с ней работают и также думают много других таких же как она сама. Но ни в коем случае ОС не должна ни на секунду (нет, секунда много, ни на такт) позволять программе выходить за ее рамки и начинать творить беспредел. Также придется обманывать, воровать и убивать. Теперь по порядку о все этом:
- обманывать - сокрытие реальных интерфейсов устройств и возможно их наличия от прикладной программы (hal, эмуляция cd)
- воровать - ну под этим я понимаю вытесняющую многозадачность, дублирование доступа к тем или иным функциям с целью разграничивания взаимодействия и т.п.
- убивать - тут все серьезно. любое даже самое мелкое нарушение прав или превышение допустимой самообороны, без суда карается смертной казнью, если на данного субъекта не распространяются особые оговорки. Если ничего не поняли, то речь идет о обработки исключительных ситуаций. Система должна работать что-бы ни случилось. Программа не умеет выкрутиться из той или иной исключительной ситуации, то система не церемонясь записывает ее состояние на диск (в случае отладочного запуска) и пришибает насекомое мухобойкой, при необходимости уведомляя пользователя и подчищая все косяки.
Это есть фишка многозадачной ОС.

 

Я всего лишь имел в виду что если в программе будет всё выровнено, то мне будет проще скопировать. Хотя какая разница.

 

На счёт того, что я сказал про выравнивание кода и данных программы по 4 КБ. Я имел в виду, что при описании странички мы ставим бит R/W (Read/Write), то есть можно ли будет записывать в эту страничку. И если мне не обращать внимание на выравнивания и всё считать смешанным - тогда нужно все странички помечать в бите R/W (Read/Write) значение 1. А если же разделять странички на код, данные (изменяемые, константы) и стек - то тогда в программе нужно будет указывать выравнивание и можно уже использовать разное значение бита R/W (Read/Write) для страничек. Понимаете что я имею в виду? Или всё под одно лучше свести?

 

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

 

По мне так единственный смысл в бите R/W это дать коду пользователя возможность читать системные структуры, но не иметь возможность их изменять. Тогда с помощью одного из бит CR4 разрешают игнорирование бита R/W для ring0 кода, а для всех системных структур (вроде дескриптора процесса) разрешают доступ из ring3, но запрещают запись. Таким образом можно сэкономить на функциях получения информации о процссах, потоках, открытых файлов, но сохранить защиту этих структур от кода пользователя.

 

SII и KIV
Спасибо! Очень полезно.

Ну а как же тогда константы реализовывать?

 

s3dworld

А что мешает иметь возможность в них записывать, но не пользоваться этой возможностью?

KIV

Ну, не только. Блокировка записи туда, куда не следует, упрощает отладку и прочее. Другое дело, что ни вынь, ни линь этим не пользуются (обратная черта кроссплатформенности: невозможность эффективно использовать возможности железа).

 

Всем доброго вечера!

Более менее начинаю вникать в процесс работы с оперативной памятью. Действительно, подкачка - это уже критический этап. Есть он, ну и хорошо. Не так уж он и важен. Мало памяти, выгружай программы. Хотя иметь на всякий пожарный подкачку - это хорошее дело.

Но вот думал я по поводу оперативной памяти и программ - так ничего и не придумал, точнее не определился. При покупке операционной системы, на диске есть информация об необходимом объёме оперативной памяти. Например, для каких то операционных систем нужно как минимум 16 МБ оперативной памяти. Пускай 8 МБ уйдёт на ядро операционной системы и 8 МБ на пользовательские программы. Вот предположим что у нас и есть эти 16 МБ оперативной памяти. Но беспокоит меня другое. Ведь программы бывают разные. Разные в плане того, сколько памяти они будут использовать. То есть и размеры всех таблиц будут разными (это я про таблицы вторых уровней). Скажем для одной программы это будет всего 16 КБ, для другой - 128 КБ. То есть нет чёткости того, сколько именно памяти уйдёт к операционной системе, а сколько на программы пользователя будет доступно. Вот я и думаю, как это всё делается. Надумал три варианта:

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

2. Можно ограничить программы. Опять же, не лучший вариант (наверное даже хуже первого)!

3. Можно внести какой-то процент использования (например, 30% - ядро операционной системы, 70% - пользовательские программы). Особо не задумывался над этим вариантом, но он очень сильно пересекается с первым вариантом!

4. Сделать динамическое ядро операционной системы. То есть в начале пускай оно занимает скажем 8 МБ и никакие программы пользователя не запущены. Есть ещё 8 МБ оперативной памяти, которая свободна. И вот программа запускается, ядро операционной системы из оставшихся 8 МБ забирает память под описание программы и оставшеюся память отдаёт программе (если ей столько нужно).

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

Всем спасибо за внимание!

 

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

 

Вот приблизительно этот вариант и используется. Только оставшиеся от 8 свободных МБ пространство не отдаётся сразу же программе, а программа, когда её потребуется говорит ядру "дай мне N сраниц памяти" и ядро, если может даёт. К тому же многие системные структуры ядра (таблицы прерываний, таблицы страниц) тоже могут выделятся из этой свободной памяти.
При маппинге памяти может получится, что нужная таблица страниц не создана (в каталоге страниц на нужном месте 0), тогда выделяется одна страница памяти под таблицу. Таким образом даже каталог страниц формируется динамически.

 

не стоит забывать, что операционная система это тоже своеобразная задача. она тоже может работать с динамическим распределением ресурсов. но также не стоит забывать, что изначально все принадлежит именно операционной системе, а уже потом распределяется между программами. кстати вы опять задумываетесь не о том. на коробке пишут объем оперативной памяти, который нужен не конкретно только ядру или чему-то там в операционной системе, а объем памяти с которым пользователь будет себя комфортно чувствовать используя эту ос. на коробке с WinXP написано где-то ок 256 Мб. на практике его вполне получается запустить на машине с 32 Мб, но этот процесс занимает около пары часов и сопровождается не однократными падениями пользовательских программ.
[add]
и вот еще. после определенного этапа написания, даже если скрупулезно составлять описания и статистику, вы просто не сможете утверждать, что ядро работает именно только с этим или только с этим. эти операции будут настолько вложены, что там сам черт сломает обе ноги в 6 местах вывихнет все что можно и свернет шею.
не стоит заморачиваться о том до чего вы не дошли еще в принципе. делайте все по порядку. к примеру вы пишете возможности процессора, а у вас есть хотя бы на словах составленный алгоритм загрузки и порядок инициализации?
ну загрузились вы в память (файл с диска), начали выполняться, а что выполняться то должно? вызов получения информации о памяти и вывод ее на экран? но это лишь молекула в мировом океане кода, который надо написать.
[add 2]
да и наступит момент, а такой момент наступит, когда вы совсем повиснете. он наступит примерно в тот момент, когда вы напишите алгоритм инициализации (когда собственно процессор должен будет работать, но делать будет нечего)

 

max7C4

Надеюсь я быстро отвисну.

В общем завтра (или послезавтра) сяду и буду составлять план. Буду идти от шага к шагу. Как мне сказали: программирование - это 20% от всего. Главное - план (алгоритм).

Если у меня появятся какие-то серьёзные вопросы, надеюсь Вы мне поможете.

Большое всем спасибо за то что помогаете мне!