Ответ 1
Ну, если вопрос просто "каков размер таблицы страниц?" независимо от того, войдет ли он в физическую память, ответ можно вычислить таким образом:
Первая физическая память. Есть 512K страниц физической памяти (512M/1K). Для каждой страницы требуется 19 бит. Добавьте это к 4 битам учетной информации и получите 23 бита.
Теперь виртуальная память. С 38-разрядным адресным пространством и размером 10 бит (1K) вам потребуется 2 28 записей в вашей таблице страниц.
Следовательно, записи таблицы таблицы 2 28 по 23 бита каждый составляют 6,174,015,488 бит или 736M.
Максимальный размер, необходимый для одноуровневой подсистемы VM для каждого процесса.
Теперь очевидно, что это не сработает, если у вас есть только 512 М физической памяти, поэтому у вас есть несколько вариантов.
-
Вы можете уменьшить количество физических страниц. Например, только половина памяти должна подвергаться пейджингу, сохраняя при этом остальную половину резидентства. Это сохранит один бит за запись, а не на самом деле, чтобы сделать разницу.
-
Увеличьте размер страницы, если это возможно. Страница 1K на 38-битном адресном пространстве является причиной очень резких таблиц страниц. Например, я думаю, что "386, с его 32-разрядным адресным пространством, использует 4K-страницы. Это приведет к записи в миллион страниц таблицы, что намного меньше, чем требуется 260 миллионов.
-
Переход на многоуровневый. Немного более продвинутый, но в основном это означает, что сами страницы страниц подвержены поисковым вызовам. Вы должны держать первый уровень таблиц страниц в физической памяти, но второй уровень может идти и исчезать по мере необходимости. Это значительно уменьшит физические требования, но за счет скорости, так как могут возникнуть два уровня сбоев страниц, чтобы попасть на фактическую страницу процесса (один для вторичных таблиц поискового вызова, а затем один для страницы процесса).
Давайте посмотрим немного ближе к варианту 3.
Если мы разрешаем 32M для основной таблицы подкачки и даем каждой записи 4 байта (32 бита: нужны только 23, но мы можем округлить для эффективности здесь), это позволит 8388 608 страниц для таблицы вторичной страницы.
Так как каждая из страниц страницы вторичной страницы имеет длину 1 КБ (позволяя нам хранить 256 записей в таблице вторичной страницы по 4 байта каждый), мы можем адресовать в общей сложности 2 147 483 648 виртуальных страниц.
Это позволит 8 192 полностью загруженного (то есть, используя все их 28-разрядное адресное пространство) процессы работать рядом друг с другом, предполагая, что у вас есть справедливый кусок дискового пространства для хранения нерезидентных страниц.
Теперь очевидно, что основная таблица подкачки (и подсистема VM, и, вероятно, справедливый кусок остальной ОС) должна постоянно оставаться резидентом. Вам не разрешается выходить на страницу с одной из основных страниц, так как вам может понадобиться эта страница, чтобы вернуть ее: -)
Но резидентная стоимость всего 32 МБ для 512 М для основной таблицы поискового вызова намного лучше, чем (как минимум, для одного полностью загруженного процесса) 736М.