OSDev

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

Долго тебе придется добирать код и инициализированные данные ядра до 4 мег. Строение и формирование пространства ядра - это вообще отдельный вопрос. Физически код и данные ядра я не различаю (секции кода и данных ядра существуют только на уровне исходников). Свой стек у ядра существует только во время начальной инициализации - располагается под базовым адресом загрузки 8000h. Потом ядро использует стеки ядра, принадлежащие различным потокам различных процессов. Хотя конечно есть процесс (т.н. первичная задача), в котором выполняется большинство служебных потоков.

У меня все прикладные кодовые страницы изначально имеют атрибут READONLY. Логически даже есть разделение на исполняемые и неисполняемые страницы, однако пока неисполняемыми в лучшем случае могут быть только стековые страницы (достигается за счет контроля лимита прикладного кодового сегмента в каждом процессе).

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

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

Ну, да. Причем обычно это происходит автоматически, если в системе достаточно памяти.

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

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Что вы понимаете под аллокацией? При переводе с английского этот термин имеет несколько терминов:
Резервирование, распределение, выделение.
К резервированию ещё вернёмся.

Организацию ВАП я не поднимал это фантом, начал писать где стек, где код, где данные.
А вот тема называется "Аллокирование страниц", а каких страниц не уточняется.
Есть физические страницы, есть виртуальные и они связаны не думаю что надо разделять обсуждения.

Вообще-то Yoda в стартовом посте четко объяснил, какой вопрос хочет рассмотреть, а потом сам в общем-то на него и ответил. Я написал про код, данные, стек в ответ на статьи по ссылкам achesnokov'а. Согласен, что в теме наблюдается полный "разброд и шатания". Если нужно будет удалить/порезать мои посты, я не против.

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

Менеджер памяти занимается распределением памяти и дефрагментатацией.
Принцип работы такой.
Ядро анализирует программу на предмет является ли она базовой(системной) или прикладной. Такой анализ можно сделать во время запуска путём проверки путей.
Программа вызывает сервис ядра запрашивая новую страницу.
Ядро передаёт управление менеджеру памяти. Менеджер проверяет относиться ли программа к системной или к прикладной и выделяет соответствующие страницы.
Распределение свободных страниц планирую так. 1 МБайт для базовых программ.
0.5 МБайт для отладчика и ядра.
Тем самым получим устойчивую систему.

PS. Да Dos отношу к серверной ОС. Просто лучше термина пока не придумал.

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

Насколько важно выделение непрерывных участков оперативной памяти?
В каких количествах непрерывные участки памяти необходимы для реализации доступа через DMA или иным образом?
В какой части оперативной памяти практически лучше иметь доступные для выделения непрерывные фрагменты оперативной памяти?

Ответы на эти вопросы влияют на выбор механизма выделения оперативной памяти. Стоит ли затрачивать существенные усилия на реализацию алгоритма объединяющего освобожденные физические страницы в непрерывные фрагменты, к примеру? Если использовать простой stack allocator (http://wiki.osdev.org/Page_Frame_Allocation) то память скорее всего разобьется на мелкие фрагменты, информация о которых в больших количествах будут в стеке (stack-allocator-а).



Еще хотелось бы обсудить таки виртуальное адресное пространство процесса (ВАП). Насколько я могу судить по guard pages. Данная структура виртуального пространства процесса предполагает использование исключительно защиту на уровне страниц. Т.е. защита на уровне сегментов не используется. Делается это, судя по всему всвязи с реализацией 64-битного режима в котором сегментация поддерживается в урезанном виде (см. http://dev64.wordpress.com/2012/11/26/ia-32-segmentation/#segmentation-ia32e-mode ). Правильно?

Еще одно уточнение. Виртуальное адресное пространство процесса разбито на 2 части: в первую входят секции 1)-5); во вторую входят секции 8)-10);
Нижняя часть виртуального адресного пространства процесса - код, статические данные, переменные и heap (куча) в секции rma.
Верхняя часть виртуального адресного пространства процесса - стек.

Что означает секция 6? Какая защита основной части процесса от "дополнительного модуля"? Насколько я могу судить - ее нет. Что такое "дополнительный модуль"? Предполагается что код программы и модуля разработан одним программистом, а не сторонними разработчиками? Какое пространство резервируется под "heap", всмысле по размеру? Как определяется сколько должно быть зарезервировано под rma.

Зачем отдельная секция для стеков дополнительных потоков? Для дополнительной защиты? Каким образом определяется местоположение дополнительных стеков в памяти. Всмысле как резервируется место под модули в данном случае?

Что значит системная программа? Она работает c правами ядра или это сделано только для выделения под неё отдельной памяти? Зачем системной программе память выделять особым, отличающимся от других программ (видимо пользовательских программ) способом?

Допустим у нас рухнуло приложение и съело всю память. Надо его убить, но при этом не уронить всю систему к примеру параллельно работает приложение которое управляет электричеством.
Так вот надо запустить диспетчер задач. А значит надо выделить для него памяти а мы не можем так как всю память уже съело одно приложение.
Второй случай у вас работает приложение которая решает большую систему уравнений, к примеру для проверки разрушиться мост/здание. Решает целый день и съело 100% памяти. А вы вдруг вспоминаете, что вам надо поставить заказ на закупку заклёпок. Убивать приложение не выход. Поэтому и резервируется память.

Что касается определения системное, я уже сказал это список базовых программ:
Файловый менеджер c набором утилит, WebGet, простой текстовый редактор(типа vi или блокнот), диспетчер процессов.
Можно сказать это тот набор программ которые поставляются в базовой поставки операционной системы.

Тут нет строго-го определения. Система сама решит что системное что нет и как распределять память для этого и нужен менеджер памяти.

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

Я использую базовую память - бывает нужна для древних устройств. Еще вроде бы нек. древние устройства могут работать только с первыми 16-ю мегами. При работе с устройствами лучше совсем не использовать память выше 4 гиг.

Думаю, что не нужно этого делать, пока действительно не появится такая необходимость. Я заложил подобный интерфейс в ядро, но пока не вижу необходимости его расширять или усложнять связанные с ним алгоритмы. В сказки про то, что участки ВАП лучше формировать из непрерывных участков физ. памяти, я не верю, пока не увижу веских доказательств этого. Из популярных алгоритмов для этих целей кроме битовой карты есть еще Buddy. Лично я использую стек практически в чистейшем виде: статический, состоящий из 32-разрядных элементов, каждый элемент содержит физический адрес отдельной 4-килобайтной страницы.

У меня 32-разрядная система. Базовая защита страничная (на уровне элементов, находящихся в каталоге страниц, т.е. каждый элемент защищает 4 мега пространства ядра). Дополнительно может использоваться защита на уровне сегментов, при которой прикладные сегменты покрывают только прикладное пространство (для включения/выключения этой защиты нужна перекомпиляция ядра).

Я дал описание только прикладного пространства, т.е. нижней части ВАП. Прикладные модули одного процесса никак не защищены друг от друга. Для масочной памяти (heap) у меня в исполняемом файле есть три поля: размер инициализированных данных, размер heap, размер heap reserve (причем каждая след. область включает предыдущую, т.е. инициализированные данные по сути тоже являются частью масочной памяти). Программист сам определяет, сколько ему нужно и чего, обычным путем. Например:

В исполняемом файле можно определить только стек первичного потока (тоже есть поля stack size, stack reserve size; здесь тоже резерв охватывает и сам стек; чтобы не было путаницы, можно называть эти поля min stack size и max stack size соответственно). Дополнительные потоки (и стеки для них) создаются программно. Стеки размещаются в верхней части прикладного пространства, модули в нижней. Если между стеками образовывается свободное пространство (вследствие удаление потока), оно не отдается в список свободных областей. Если приложение попытается распределить свободную страницу непосредственно под самым нижним стеком (например, явно укажет подходящий вирт. адрес), то у него могут возникнуть проблемы с созданием новых потоков.

Для решения подобной проблемы могут быть и другие подходы. Например, как это было еще давно в FreeBSD, к примеру, ограничивать количество доступной приложениям память. Чтобы приложение случайно "не съело" всю память.

В QNX, например, в 6.4 пошли дальше. В нем система жестких приоритетов. Поэтому определенным приложениям можно не только запрещать использовать больше определенного количества памяти, но и ограничивать использование приложениями процессорного времени. Называется то-ли "partitions" то-ли "domains". Уже не помню, 3 года уже к QNX не подходил. Смотреть документацию, если что.

Опять же если приложение "съело" всю память, его можно "отсвопить" для освобождения необходимой для работы памяти.