Нет, процессы пользовательского пространства работают только с виртуальными адресами (32-разрядные в вашем примере).
Память, которую они «видят», является их собственным виртуальным адресным пространством. (Они могут совершать системные вызовы, такие как mmap и munmap, чтобы запросить, чтобы страницы в этом адресном пространстве были поддержаны файлами или анонимным ОЗУ, как для C malloc.) Но они ничего не знают о том, где в физическая память, на которой расположены эти страницы.
ОС может даже "подделать" ее, выкладывая некоторые из своих страниц, чтобы обменять пространство / файл подкачки, и обработать ошибку страницы, если процесс коснетсятакую страницу, выполнив ввод-вывод, чтобы вернуть ее обратно, а затем активировать процесс для повторного запуска инструкции загрузки или сохранения, на которой произошла ошибка.
Аппаратное обеспечение преобразует виртуальные адреса в физические адреса на . каждый доступ к памяти. Чтобы сделать это быстро, TLB кэширует недавно использованные переводы. В случае пропуска TLB аппаратное обеспечение выполняет «обход страниц», читая таблицы страниц, чтобы найти правильную виртуальную страницу-> перевод физической страницы.
ОС управляет таблицами страниц, выбирая любую физическую страницу в качестве «резервной копии». для виртуальной страницы.
Физические адреса шире, чем виртуальные?
В многозадачной ОС могут выполняться несколько процессов. Каждый из них имеет свое собственное 32-разрядное (4 ГБ) виртуальное адресное пространство.
Размер физического адресного пространства ограничивает объем ОЗУ, который можно поместить в общее количество компьютеров, и можетотличаться от того, сколько любой отдельный процесс может использовать одновременно. Изменение таблиц страниц происходит быстрее, чем чтение с диска, поэтому, даже если все они не могут быть отображены одновременно, ядро все равно может использовать много физической памяти для кэша страниц (кэш содержимого файла с диска).
Что еще более важно, может быть запущено несколько процессов, каждый с собственным виртуальным адресным пространством объемом до 4 ГБ, поддерживаемым физической памятью, вплоть до объема физической памяти в системе. На ЦП с несколькимиядра, они могут работать одновременно, что позволяет одновременно использовать более 4 ГБ ОЗУ. Но не с помощью какого-либо отдельного процесса.
x86 является хорошим примером здесь: запуск ядра x86-64 с 32-разрядным пользовательским пространством дает нам в значительной степени описанную вами ситуацию. (64-битное ядро может использовать 64-битные виртуальные адреса, но не обращайте на это внимания, просто посмотрите на пространство пользователя.)
Вы можете иметь несколько процессов каждый , используя около 4 ГБ физической ОЗУ.
В формате таблицы страниц x86-64 есть место для физических адресов шириной до 52 бит, хотя текущее HW не использует так много. (Только в объеме оперативной памяти, который он на самом деле поддерживает присоединение. Сохраняет биты в TLB и других частях ЦП). https://en.wikipedia.org/wiki/X86-64#Architectural_features
До появления x86-64 32-разрядные ядра x86 могли использовать тот же формат таблиц страниц, но с 36-разрядными физическими адресами на процессорах Pentium Pro и более поздних версий. https://en.wikipedia.org/wiki/Physical_Address_Extension. Это позволило до 64 ГБ физической памяти. (32-разрядное ядро обычно резервирует для себя 1 или 2 ГБ виртуального адресного пространства, поэтому каждый процесс может использовать только до 3 или 2 ГБ, но это та же идея. Не проблема для 32-разрядного пользовательского пространства под 64-битное ядро, так что это сделал более простой пример.)