Зачем нам нужна виртуализация адресов в операционной системе?

Question

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

В основном, процессор (современные микропроцессоры) генерирует виртуальные адреса, а затем MMU (блок управления памятью) заботится о переводе этих виртуальных адресов на соответствующие им физические адреса в ОЗУ. Пример, предложенный профессором, заключается в необходимости виртуализации, потому что скажем, например: вы компилируете программу на C. Вы запускаете его. И затем вы скомпилируете другую программу на C. Вы пытаетесь запустить его, но резидентная работающая программа в памяти предотвращает загрузку более новой программы, даже когда пространство доступно.

С моей точки зрения, я думаю, что не имеет виртуализации, если компилятор генерирует два физических адреса, которые являются одинаковыми, второй не будет работать, потому что он считает, что для него недостаточно места. Когда мы виртуализируем это, так как в CPU генерируются только виртуальные адреса, MMU будет заниматься этим «столкновением» и найти место для другой программы в ОЗУ. (Наш профессор привел пример MMU, являющегося таблицей сопоставления, которая принимает виртуальный адрес и сопоставляет его с физическим адресом). Я думал, что эта идея очень похожа на разрешение конфликтов в хеш-таблице.

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

Answer 1

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

Ваше понимание примерно верно.

Разъяснения:

• Структуры данных не имеют ничего общего с хэш-таблицы.

• Во всяком случае, структуры данных ближе к BTree, но даже есть важные отличия. Это действительно самое близкое к (Java) N-мерному массиву, который был распределен редко.

• Это сопоставление страниц, а не полные виртуальные/физические адреса. (Полный адрес - адрес страницы + смещение внутри страницы.).

• Нет проблем с столкновением. В любой момент времени виртуальные -> физические сопоставления для всех пользователей/процессов дают однозначное отображение из (идентификатор процесса + виртуальная страница) на физическую страницу ОЗУ или на страницу диска (или и то, и другое).

---

Причины, которые мы используем виртуальную память являются:

• изоляция процесса; то есть один процесс не может видеть или вмешиваться в другую память процессов

• упрощает написание заявки; то есть каждый процесс считает, что он имеет непрерывный набор адресов памяти и один и тот же набор каждый раз. (В первом приближении ...)

• упрощение составления, связывания, погрузки; то естькомпиляторам и т. д. нет необходимости «передислоцировать» код во время компиляции или времени выполнения, чтобы учесть другие.

• , чтобы позволить системе разместить больше процессов, чем физическое ОЗУ, хотя это связано с потенциальными рисками и штрафами за производительность.

Answer 2

Я думаю, что у вас есть фундаментальное заблуждение относительно того, что происходит в операционной системе в отношении памяти.

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

К сожалению, термины «логическая память» и «виртуальная память» объединяются, но они представляют собой различные концепции, причем различие становится все более важным.

(2) Программы, запущенные в ПРОЦЕССЕ. Процесс обрабатывает только одну программу за раз (в Unix каждый процесс обычно запускает только одну программу (два, если вы считаете клонированного абонента) в своей жизни.

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

В 32-разрядной системе адреса 0-7FFFFFFF могут быть адресами пользователей, которые (как правило) сопоставлены с уникальными физическими местоположениями, а 80000000-FFFFFFFFmight сопоставляются с системным адресным пространством, которое одинаково для всех процессов.

(3) Логическое управление памятью в основном служит средством обеспечения безопасности; а не как средство загрузки программ (хотя в этом и помогает).

(4) Этот пример не имеет смысла для меня:

Вы компилировать программу C. Вы запускаете его. И затем вы скомпилируете другую программу на C. Вы пытаетесь запустить его, но резидентная работающая программа в памяти предотвращает загрузку более новой программы, даже когда пространство доступно.

Вы игнорируете концепцию ПРОЦЕССА. Процесс может работать только одна программа за раз. В системах, которые позволяют серийный запуск программ с одним и тем же процессом (например, VMS), исполняющая программа предотвращает загрузку другой программы (или загрузка другой программы приводит к завершению работы программы). Это не проблема памяти.

(5) Это не правильно вообще:

Из моего понимания, я думаю, не имея виртуализации, если компилятор генерирует два физических адреса, которые являются одинаковыми, то второй не будет работать потому, что он считает, что для этого недостаточно места. Когда мы виртуализируем это, так как в CPU генерируются только виртуальные адреса, MMU будет заниматься этим «столкновением» и найти место для другой программы в ОЗУ.

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

Когда программа обращается к логической памяти колючек последовательность:

1. ломаются адреса в страницу и смещение внутри страницы.
2. Имеет ли страница соответствующую запись в таблице страниц? Если не FAULT.
3. Действительно ли запись в таблице страниц действительна? Если не FAULT.
4. Позволяет ли запись в таблице страниц запрашивать тип доступа (чтение/запись/выполнение) в текущем режиме работы (ядро/пользователь/...)? Если не FAULT.
5. Отображается ли карта входа на физическую страницу? Если не PAGE FAULT (перейдите на страницу с диска - виртуальная память - и повторите попытку).
6. Доступ к физической памяти, на которую ссылается таблица страниц.