OSDev

для всех
Текущее время: 19 ноя 2019, 14:31

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 19 июн 2013, 22:10 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1204
achesnokov писал(а):
Под базовой вы понимаете память статически выделенную в исходном коде? Статически - всмысле константный адрес. Правильно?
Нет, под базовой я понимаю память в первом меге физ. адресного пространства. Кстати статически я распределяю память тоже только в первом меге. Т.е. физ. адрес начального каталога страниц и т.п. заранее не известен.

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

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

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

Цитата:
Что касается выделения физической памяти. Самый простой концепт - битовая маска, скорее всего, будет медленно работать. Да и память занимать будет. Список свободных блоков, возможно вариант лучше. У James Molloy был описан подобный вариант... Есть куча классических механизмов, последний из которых, кажется Slub Allocation.... Было бы много что интересно обсудить...
Стек свободных страниц требует больше памяти, хотя у стека значительно проще забирать неиспользуемую им память, чем у битовой маски. Основная проблема битовой маски - это поиск свободной страницы. Slab - это немного другое - позволяет быстро и экономично выделять маленькие участки определенных размеров для повторного использования.

Цитата:
Стековый резерв - судя по всему пространство зарезервированное под увеличение стека, если его не хватит. Правильно?
Ну, да. Причем обычно это происходит автоматически, если в системе достаточно памяти.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 00:41 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 963
Откуда: Дагоба
pavia писал(а):
ВАП описывается деревом состоящим из корня(каталог таблиц страниц) ветвями дерева являются таблицы страниц. И листьями страницы. В общем случае такое дерево может быть многоуровневым.

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

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 08:37 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1117
Yoda писал(а):
pavia писал(а):
ВАП описывается деревом состоящим из корня(каталог таблиц страниц) ветвями дерева являются таблицы страниц. И листьями страницы. В общем случае такое дерево может быть многоуровневым.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 09:52 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 10:44 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 12:00 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
Позволю себе задать еще несколько вопросов. Изначальный тред про выделение-освобождение физических страниц. Начну с вопроса про выделение физической памяти.

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

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

phantom-84 писал(а):
Для примера мой вариант разметки прикладного пространства:
1) stop frame (guard page(s));
2) секция кода;
3) секция данных;
4) секция bss - изначально не выравнивается на границу страницы;
5) секция rma (предназначена для резервирования участка ВАП) - изначально не выравнивается на границу страницы;
6) свободное пространство - здесь может быть размещен след. модуль;
7) здесь могут быть размещены стеки доп. потоков;
8) стековый stop frame (guard page(s));
9) стековый резерв;
10) стек.
В принципе начальный состав секций отдельно взятого модуля может меняться, но в данный момент я использую такой формат исполняемых файлов, при котором это невозможно.


Еще хотелось бы обсудить таки виртуальное адресное пространство процесса (ВАП). Насколько я могу судить по 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.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 13:52 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
pavia писал(а):
Ядро анализирует программу на предмет является ли она базовой(системной) или прикладной. Такой анализ можно сделать во время запуска путём проверки путей.
Программа вызывает сервис ядра запрашивая новую страницу.
Ядро передаёт управление менеджеру памяти. Менеджер проверяет относиться ли программа к системной или к прикладной и выделяет соответствующие страницы.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 14:21 
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 14:42 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1204
Цитата:
Насколько важно выделение непрерывных участков оперативной памяти?
В каких количествах непрерывные участки памяти необходимы для реализации доступа через DMA или иным образом?
Лично я считаю, что особо и не нужно. Все современные устройства, насколько я знаю, могут спокойно работать с раскиданными по разным местам участками физ. памяти. Мне для работы с хардом к примеру вообще не нужны смежные страницы. Реализовал на всякий случай небольшой пул для выделения непрерывных участков, чтобы такой сервис был. Использую только для флоппиков.

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

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

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

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

Что означает секция 6? Какая защита основной части процесса от "дополнительного модуля"? Насколько я могу судить - ее нет. Что такое "дополнительный модуль"? Предполагается что код программы и модуля разработан одним программистом, а не сторонними разработчиками? Какое пространство резервируется под "heap", всмысле по размеру? Как определяется сколько должно быть зарезервировано под rma.
Я дал описание только прикладного пространства, т.е. нижней части ВАП. Прикладные модули одного процесса никак не защищены друг от друга. Для масочной памяти (heap) у меня в исполняемом файле есть три поля: размер инициализированных данных, размер heap, размер heap reserve (причем каждая след. область включает предыдущую, т.е. инициализированные данные по сути тоже являются частью масочной памяти). Программист сам определяет, сколько ему нужно и чего, обычным путем. Например:
Код:
section BSS
{
  align 4
  var dd ?
}

section RMA
{
  align4M ; в fasm'е прокатывают и такие трюки
  buffer rb 400000h
}


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


Последний раз редактировалось phantom-84 20 июн 2013, 14:58, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аллокирование страниц
СообщениеДобавлено: 20 июн 2013, 14:58 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
pavia писал(а):
Допустим у нас рухнуло приложение и съело всю память. Надо его убить, но при этом не уронить всю систему к примеру параллельно работает приложение которое управляет электричеством.
Так вот надо запустить диспетчер задач. А значит надо выделить для него памяти а мы не можем так как всю память уже съело одно приложение.
Второй случай у вас работает приложение которая решает большую систему уравнений, к примеру для проверки разрушиться мост/здание. Решает целый день и съело 100% памяти. А вы вдруг вспоминаете, что вам надо поставить заказ на закупку заклёпок. Убивать приложение не выход. Поэтому и резервируется память.


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

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB