Как сэкономить место с перевернутыми таблицами страниц?

Question

Почему мы сохраняем память, если мы используем инвертированные таблицы страниц для сопоставления виртуальных адресов с физическими? Если у нас есть, например, два процесса, которые оба имеют 4 страницы, мы имели бы 8 записей в двух разных таблицах, указывающих от виртуального к физическому адресу:

Process 1: 
[0] = 1 
[1] = 5 
[2] = 63 
[3] = 0 

Process 2: 
[20] = 14 
[21] = 55 
[22] = 11 
[25] = 9 

Если мы будем использовать перевернутые таблицы страниц мы имели бы только один большой стол, указывающие это наоборот. Но по размеру они равны.

2) Inverted page table 

[0] = <p1 | 3> 
[1] = <p1 | 0> 
[5] = <p1 | 1> 
[9] = <p2 | 25> 
[11]= <p2 | 22> 
[14]= <p2 | 20> 
[55]= <p2 | 21> 
[63]= <p1 | 2> 

Answer 1

Таблица страниц должна быть на одном блоке (вы получаете страницы как в массиве). Вы получаете 2 вещи из перевернутого стола.

Стол-лист становится меньше, например, вместо размера стола 2^20 и смещения 2^12, вы получаете размер стола 2^10 dir.

Тогда вместо получения (2^20) * (2^2) Байт памяти для таблицы страниц большинство страниц будут отображаться на диске, и вы получите выделение только в том случае, если процесс им нужен.

В вашем случае вместо всего процесса будет отображаться таблица страниц размером 2^20 * 2^2 байтов, у вас будет только 2^10 * 2^2 байта для таблицы, а другая 2^10 * 2^2 байтов для таблицы страниц. это большая разница, вместо 2^22 байта у вас есть 2^13.

Я надеюсь, что было ясно.

Answer 2

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

Но перевернутая хэш-таблица представляет собой глобальная структура данных .The ОС, которая использует эту технику будет использовать какой-то механизм блокировки, чтобы дать доступ только один процесс в данный момент времени. (2 представьте процесс на 2 ядра Доступ к глобальные данные одновременно).

Предполагая, что размер 4 ГБ для каждого процесса и размер страницы 4096, в первом случае каждый процесс имеет 4 ГБ/4096 (нет записей в таблице страниц * размера каждой записи в таблице страниц), и все это будет потреблять пространство, для каждого процесса, который создается/forked. Общая память, используемая для сопоставления виртуального на физическое, представляет собой общую сумму размера таблицы страницы для всего процесса. Это более простой подход, поскольку на каждом коммутаторе контекста вы будете менять указатель, ничего сложного.

Во втором случае у вас будет отдельная таблица с записями 4GB/4096, поэтому пространство сохраняется, но управление памятью становится сложным, так как это глобальные данные, вам нужно будет добавить дополнительную информацию в каждую запись, как нынешний владелец (как вы показали) и т. д. MMU/OS должна заботиться о синхронизации.

Но приведенный вами пример не является точным, на реальной системе с каждой страницей страницы процесса доступен весь адрес, в вашем случае процесс p1 имеет 4 страницы, а p2 - другой набор страниц. На самом деле оба процесса могут получить доступ к одному и тому же виртуальному адресу, сопоставленному с другим физическим фреймом. Каждая таблица в вашей таблице должна иметь по 8 записей.