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