Поле адреса таблицы страниц для некэшированной страницы

Поле адреса таблицы страниц для некэшированной страницы

Согласно (несколько абстрактной) модели таблицы страниц в системах, подобных Linux, Брайанта и О'Халларона, каждая запись таблицы страниц (PTE) имеет поле адреса, которое содержит одно из трех значений: (1) физический адрес (фактически, номер страницы), с которым сопоставлена ​​виртуальная страница; (2) эквивалентный идентификатор местоположения для долгосрочного запоминающего устройства — где может быть найдена страница; или (3) 0 для нераспределенной страницы. Предположим, что страница была выгружена из долгосрочного хранилища в основную память. В этом случае ядро ​​заменяет адрес долгосрочного хранилища (2) на физический адрес (1). Теперь предположим, что ту же страницу в физической памяти необходимо вытеснить, чтобы освободить место для какой-то другой страницы для выгрузки. Как исходный адрес долгосрочного хранилища восстанавливается в PTE, если он был перезаписан физическим адресом? Спасибо.

решение1

PTE представляютвиртуальныйстраницы. Как вы говорите, когда виртуальная страница присутствует в основной памяти, поле адреса PTE будет содержать физический номер кадра страницы (PFN).

Каждыйфизическийстраница имеет соответствующий struct page. Это имеет:

Далее следует flags:

struct address_space *mapping;

Для страниц, которые находятся в кэше страниц (большая часть страниц в большинстве систем), mappingуказывает на информацию, необходимую для доступа к файлу, который создает резервную копию страницы. Если, однако, страница является анонимной страницей (память пользовательского пространства, поддерживаемая подкачкой), то mappingбудет указывать на anon_vmaструктуру [...]

--Втиснуть больше информации в страницу структуры, LWN.net

Затем это page→indexполе используется для хранения swp_entry_tструктуры анонимных страниц. (Для страниц в кэше страниц это поле содержит смещение файла).

swp_entry_tсодержит индекс устройства подкачки и местоположение на этом устройстве подкачки.

Конкретные подробности того, как это работало в... 2004 году... можно найти вПонимание диспетчера виртуальной памяти Linux — управление подкачкой, написанный Мелом Горманом.

решение2

Из вашего вопроса мне не совсем понятно, спрашиваете ли вы о mmap()ped-файлах, свопе или пассивно отображенных файлах в кэше страниц, поэтому отвечу за все.

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

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

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

Связанный контент