OSDev

для всех
Текущее время: 20 июн 2018, 18:10

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




Начать новую тему Ответить на тему  [ Сообщений: 9 ] 
Автор Сообщение
 Заголовок сообщения: Память и менеджер памяти
СообщениеДобавлено: 04 апр 2009, 17:32 

Зарегистрирован: 04 апр 2009, 17:22
Сообщения: 7
Ктонить этим уже занимался? помогите в теории: как это реализуется?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Память и менеджер памяти
СообщениеДобавлено: 05 апр 2009, 14:00 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1055
Откуда: Балаково
Должен быть общий массив занятых физических страниц памяти, и для каждого процесса каталоги страниц с директорией страниц. При заполнении каталогов виртуальных страниц, менеджер берёт их из массива физических страниц. При освобождении каталогов, физические страницы заносятся обратно в массив физических страниц.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re^2: Память и менеджер памяти
СообщениеДобавлено: 05 апр 2009, 14:38 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1344
Откуда: Зеленоград
Вообще-то directory -- это и есть каталог... А способов реализации -- миллион, общим остаётся лишь самое очевидное: для каждого процесса должен быть список областей памяти, коими он владеет, и их соответствия со страницами физической памяти и областями файла подкачки, плюс у системы в целом должен быть список свободных страниц. Причём "список" в данном случае не указывает на конкретную структуру данных, хранить можно и в массиве, и в двоичном дереве, и в списке в собственном смысле слова (односвязном или двусвязном)...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re^2: Память и менеджер памяти
СообщениеДобавлено: 06 апр 2009, 22:19 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1196
>Должен быть общий массив занятых физических страниц памяти
Не факт. Если можно обеспечить надежный возврат страниц в системный пул даже из "проблемных" процессов и перераспределение страниц между процессами с течением времени хотябы при периодической активации этих процессов, то общесистемный массив занятых страниц можно и не использовать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Память и менеджер памяти
СообщениеДобавлено: 06 апр 2009, 22:33 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1196
>у нас должна быть некоторая запись описания процесса. для процесса должен быть массив занятых физических страниц памяти? или у нас должны быть каталоги страниц и директории страниц для каждого процесса?

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Память и менеджер памяти
СообщениеДобавлено: 08 апр 2009, 02:51 

Зарегистрирован: 04 апр 2009, 17:22
Сообщения: 7
а может ктонить в _очень_ простым языком объяснить как делается менеджер?

если я правильно понимаю то так:
1. получение памяти
- найти незанятую область в памяти (для этого используется карта занятости физическиз страниц) и пометить как занятую
- добавить в таблицу страниц процесса указатель на эту страницу
- если таблица закончилась, то:
- найти незанятую область в памяти и пометить ее как занятую
- добавить указатель на эту область в каталог страниц процесса
2. кэширование памяти
- найти "чистые" страницы
- сохранить на диск
- пометить страницы как незанятые
3. освобождение процесса
- пометить все занятые страницы процесса как незанятые
- пометить все страницы с директориями и таблицами страниц как незанятые

так?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re^2: Память и менеджер памяти
СообщениеДобавлено: 08 апр 2009, 04:10 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1344
Откуда: Зеленоград
_Очень_ простым языком это объяснить проблематично, поскольку сама ось (и её ключевые компоненты) -- вещь весьма сложная :)

Насчёт Ваших последующих выкладок сразу сделаю одно замечание: Вы смешиваете управление памятью и управление процессами. Понятно, что эти вещи пересекаются, однако их всё же надо чётко разделять. Но в первую очередь надо полностью определиться с терминологией, и в частности, с термином "процесс". Например, в Винде и в Линухе это хотя и близкие вещи, но не одно и то же (а между Виндой и классическим Унихом разницы ещё больше). Лично я в целом придерживаюсь терминологии Винды: и сама система мне ближе, и её концепция (а значит, и термины) продуманнее, чем в Линухе. Поэтому для меня процесс (process) -- это некая сущность, владеющая ресурсами: процессу принадлежит область виртуальной памяти (не обязательно непрерывная), открытые файлы, события, мьютексы, семафоры, таймеры и прочие объекты, которыми через соответствующие вызовы АПИ системы можно манипулировать. Однако процесс не может исполняться, вместо этого ему принадлежит один или несколько потоков (thread), которые и являются исполняемыми сущностями (можно считать, что поток -- это набор регистров процессора, включая все регистры общего назначения, EFLAGS и EIP), но не владеют ресурсами, а разделяют друг с другом ресурсы, коими владеет процесс (т.е. у потока нет "личных" событий, файлов, памяти и т.п.). Далее тему процессов и потоков развивать здесь не буду, просто ещё раз обращаю Ваше внимание на то, что с терминами нужно чётко определиться, иначе неизбежна путаница.

И ещё немного о терминах. Если мы обратимся к мануалам на процессоры IA-32, то увидим, что для преобразования линейных адресов в физические в общем случае используются:

- page table, т.е. таблица страниц;
- page directory, каталог страниц ("директория" -- калька с английского наших горе-авторов второй половины 1980-х -- начала 1990-х, которые ни русского толком не знают, ни английского; впрочем, не об этом речь);
- page directory pointer table, таблица указателей на каталоги страниц;
- PML4 table (page map level 4 table), таблица карты страниц 4-го уровня.

При простом 32-разрядном преобразовании задействованы только первые два вида таблиц, но если предполагается уметь формировать физический адрес, выходящий за пределы 4 Гбайт (а это неоходимо, если есть желание использовать всю установленную на ПК память объёмом свыше примерно 2,5 Гбайт), то надо использовать как минимум три уровня. Принципиально на работе менеджера памяти это не сказывается, но "в уме" держать такие вещи приходится -- в первую очередь из-за того, что оси в такой ситуации приходится иметь дело не с 32-, а 36- или 64-разрядными физическими адресами (последние, впрочем, только в 64-разрядном режиме).

Переходя же собственно к менеджеру памяти, можно выделить следующие его функции:

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

2) Освобождение виртуальной памяти процесса -- опять-таки постранично, по запросам потоков этого процесса (для краткости можно говорить, что память запрашивает или освобождает процесс, но нужно помнить, что физически это делает один из его потоков, поскольку именно поток является исполняемой сущностью) или при завершении процесса;

3)Выделение страниц физической памяти и установление отображения страниц виртуальной памяти процессов на страницы физической памяти;

4) Отъём у процессов ранее выделенных им страниц физической памяти с выгрузкой их содержимого в файл подкачки или без оного (зависит от причин отъёма);

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

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

7) Отдельным пунктом можно выделить выделение и отъём страниц физической памяти, используемых в качестве дискового кэша -- это зависит во многом от того, как в оси реализована подсистема ввода-вывода.

Ну а расписывать по пунктам, какие конкретно действия выполняются для решения этих задач, я особого смысла не вижу: куда важнее чётко определить набор сервисов (фактически -- подпрограмм), которые менеджер памяти предоставляет другим компонентам системы, а переходить к более подробной детализации можно лишь после этого. Понятно, что для получения физической страницы надо сначала найти свободную, ну а что делать, если свободных нет? Как в этом случае происходит отъём страницы у какого-либо процесса и передача её другому процессу, особенно учитывая, что на скидывание её содержимого на диск и загрузку нового содержимого уходит огромное количество времени?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re^3: Память и менеджер памяти
СообщениеДобавлено: 08 апр 2009, 22:57 

Зарегистрирован: 04 апр 2009, 17:22
Сообщения: 7
термины:
процесс - пусть упрощенно, это некая сущность как в описании выше.
нить - это т.н. "thread", каждая задача может иметь несколько нитей. т.е. по сути отделный tast для процессора.
задача - это т.н. "task", который создается и выполняется процессором в системе.


Цитата:
_Очень_ простым языком это объяснить проблематично, поскольку сама ось (и её ключевые компоненты) -- вещь весьма сложная :)

а может всё-таки кто-нибудь сможет объяснить, если опустить все сложности процессоров >=i486..
а именно:
- необходимый минимум для выполнения нескольких задач
- использования i386
- использование страничного режима с двумя таблицами (как я понимаю они должны быть для каждой задачи?) Page-directory и Page-table (4-х килобайтовые)

что именно я не понимаю:
- если таблицы должны быть для каждого процесса, то получается если запускаемая программа состоит из 2 байт, то для нее выделится страница памяти 4К + страница для PD 4К + страница для PT 4К + память для описания процесса + память для TSS + память для LDT. Т.е. получается сразу выделяется >12КБайт для одной задачи.
- допустим есть рабочая система. У нас выполняется задача. И в этой задаче мы обращаемся к памяти по логическому адресу, а физической страницы нет ни в памяти ни в таблицах страниц. Мы вываливаемся в interrupt 14 (page fault). И вот тут что должно происходить? Мы должны выделить страницу и создать указатель в таблицах страниц?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re^4: Память и менеджер памяти
СообщениеДобавлено: 08 апр 2009, 23:32 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1055
Откуда: Балаково
Верно. При этом обработчик исключения 14 узнаёт требуемый адрес из регистра CR2.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 9 ] 

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


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

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


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

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