|
_Очень_ простым языком это объяснить проблематично, поскольку сама ось (и её ключевые компоненты) -- вещь весьма сложная :)
Насчёт Ваших последующих выкладок сразу сделаю одно замечание: Вы смешиваете управление памятью и управление процессами. Понятно, что эти вещи пересекаются, однако их всё же надо чётко разделять. Но в первую очередь надо полностью определиться с терминологией, и в частности, с термином "процесс". Например, в Винде и в Линухе это хотя и близкие вещи, но не одно и то же (а между Виндой и классическим Унихом разницы ещё больше). Лично я в целом придерживаюсь терминологии Винды: и сама система мне ближе, и её концепция (а значит, и термины) продуманнее, чем в Линухе. Поэтому для меня процесс (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) Отдельным пунктом можно выделить выделение и отъём страниц физической памяти, используемых в качестве дискового кэша -- это зависит во многом от того, как в оси реализована подсистема ввода-вывода.
Ну а расписывать по пунктам, какие конкретно действия выполняются для решения этих задач, я особого смысла не вижу: куда важнее чётко определить набор сервисов (фактически -- подпрограмм), которые менеджер памяти предоставляет другим компонентам системы, а переходить к более подробной детализации можно лишь после этого. Понятно, что для получения физической страницы надо сначала найти свободную, ну а что делать, если свободных нет? Как в этом случае происходит отъём страницы у какого-либо процесса и передача её другому процессу, особенно учитывая, что на скидывание её содержимого на диск и загрузку нового содержимого уходит огромное количество времени?
|
Вход
Регистрация
FAQ
Поиск
