
Согласно (несколько абстрактной) модели таблицы страниц в системах, подобных Linux, Брайанта и О'Халларона, каждая запись таблицы страниц (PTE) имеет поле адреса, которое содержит одно из трех значений: (1) физический адрес (фактически, номер страницы), с которым сопоставлена виртуальная страница; (2) эквивалентный идентификатор местоположения для долгосрочного запоминающего устройства — где может быть найдена страница; или (3) 0 для нераспределенной страницы. Предположим, что страница была выгружена из долгосрочного хранилища в основную память. В этом случае ядро заменяет адрес долгосрочного хранилища (2) на физический адрес (1). Теперь предположим, что ту же страницу в физической памяти необходимо вытеснить, чтобы освободить место для какой-то другой страницы для выгрузки. Как исходный адрес долгосрочного хранилища восстанавливается в PTE, если он был перезаписан физическим адресом? Спасибо.
решение1
PTE представляютвиртуальныйстраницы. Как вы говорите, когда виртуальная страница присутствует в основной памяти, поле адреса PTE будет содержать физический номер кадра страницы (PFN).
Каждыйфизическийстраница имеет соответствующий struct page
. Это имеет:
Далее следует
flags
:struct address_space *mapping;
Для страниц, которые находятся в кэше страниц (большая часть страниц в большинстве систем),
mapping
указывает на информацию, необходимую для доступа к файлу, который создает резервную копию страницы. Если, однако, страница является анонимной страницей (память пользовательского пространства, поддерживаемая подкачкой), тоmapping
будет указывать наanon_vma
структуру [...]
Затем это page→index
поле используется для хранения swp_entry_t
структуры анонимных страниц. (Для страниц в кэше страниц это поле содержит смещение файла).
swp_entry_t
содержит индекс устройства подкачки и местоположение на этом устройстве подкачки.
Конкретные подробности того, как это работало в... 2004 году... можно найти вПонимание диспетчера виртуальной памяти Linux — управление подкачкой, написанный Мелом Горманом.
решение2
Из вашего вопроса мне не совсем понятно, спрашиваете ли вы о mmap()
ped-файлах, свопе или пассивно отображенных файлах в кэше страниц, поэтому отвечу за все.
В случае не mmap вытеснение есть вытеснение: как только страница становится чистой, ее можно просто удалить. Когда страница, не подкрепленная файлом, вытесняется из основной памяти, обычно нет необходимости восстанавливать какой-либо адрес, поскольку они просто выведут ошибку страницы в новую запись кэша при следующем доступе к файлу. Аналогичная вещь происходит в случае подкачки: если мы выведем страницу из подкачки и позже должны будем вытеснить ту же страницу, мы, скорее всего, просто дадим новый адрес подкачки в следующий раз и установим его в PTE (или используем кэш подкачки, если страница там присутствует и чистая).*
В случае mmap жизненный цикл контролируется системным mmap()
вызовом. Диапазон явно отображается на непрерывную часть виртуальной памяти на mmap()
, а метаданные для этого отображения (например, резервный FD, на который у нас есть счетчик ссылок, смещение, размер и т. д.) хранятся в соответствующей области виртуальной памяти (VMA). Даже когда страницы вытесняются, VMA сохраняет информацию о отображении, позволяя ядру знать, откуда следует выполнить сбой при следующем доступе.
* В действительности ни подкачка, ни общая активность подкачки обычно не происходят на уровне страницы, а вместо этого часто происходят на более низком уровне детализации, например, кластер подкачки или пакет упреждающего чтения.