1) Где хранится таблица страниц для каждого процесса? Как часть блока управления процессом?
Обычно это не «таблица страниц». Для некоторых процессоров есть только записи TLB (записи Translation Lookaside Buffer - например, кэш того, что представляют собой переводы), где программное обеспечение должно обрабатывать «промах TLB», загружая все, что чувствует, в сам TLB, и где ОС может не использовать таблицы вообще (например, можно использовать «список зон произвольной длины»). Для некоторых процессоров это иерархия нескольких уровней (например, для современных 64-битных 80x86 есть 4 уровня); и в этом случае некоторые из уровней могут быть в физической памяти, а некоторые могут находиться в пространстве подкачки или где-то еще, а некоторые могут быть сгенерированы по мере необходимости из других данных (немного похоже на то, что было бы для «программной обработки пропусков TLB»). «). В любом случае, если каждый процесс имеет свое собственное виртуальное адресное пространство (например, и это не своего рода схема «одноадресного пространства, совместно используемого многими процессами»), вполне вероятно, что блок управления процессом (прямо или косвенно) содержит ссылку на что-либо ОС использует (например, может быть один «физический адрес для таблицы страниц самого высокого уровня», но может быть виртуальный адрес «списка зон произвольной длины» и, возможно, чего-либо еще).
2) Содержит ли таблица страниц записи для нераспределенной памяти, чтобы можно было обнаружить segfault (проще)?
Если существуют таблицы страниц, то должен быть способ указать «страница отсутствует», где «страница не присутствует» может означать, что память не выделена, но может также означать, что (виртуальная) память была выделена, но запись для нее не установлена (либо потому, что ОС генерирует таблицы по требованию, либо потому, что фактические данные находятся в пространстве подкачки, или ...).
3) Возможно ли это (и используется ли в любой известной соответствующей ОС) у одного процесса есть несколько размеров фрейма страницы?
Да. Это относительно распространено для 64-битных 80x86, где есть 4 страницы по 2 КБ, 2 МБ (или 4 МБ) «большие страницы» (плюс, может быть, 1 ГБ «огромные страницы»); и сделано, чтобы уменьшить вероятность пропусков TLB (одновременно уменьшая объем памяти, используемой таблицами страниц). Обратите внимание, что в основном это артефакт наличия нескольких уровней таблиц страниц - запись в таблице более высокого уровня может сказать «эта запись является большой страницей» или она может сказать «эта запись представляет собой таблицу страниц более низкого уровня, которая может содержать страницы меньшего размера. ». Обратите внимание, что в данном случае это не «несколько размеров страницы в одной таблице», а «фиксированный размер страницы для каждого уровня».
Особенно, если вопрос 2 верен, очень удобно отображать огромные таблицы страниц в несуществующую память, чтобы сохранить таблицу страниц как можно меньше. Это все еще позволит с высокой точностью отображать меньшие кадры в память, чтобы сохранить внешнюю (и внутреннюю) фрагментацию как можно меньше? Это, конечно, требует дополнительного поля, хранящего размер кадра для каждой записи. Пожалуйста, укажите причину (и), если моя «идея» не может существовать.
Преобразование виртуального адреса в физический адрес (или какая-то ошибка, указывающая на то, что перевода не существует) необходимо быть очень быстрым (потому что это случается очень часто). Когда у вас есть «фиксированный размер страницы для каждого уровня», это означает, что вы можете извлечь некоторые биты виртуального адреса и использовать их в качестве индекса в таблице; это быстро.
Когда у вас «несколько размеров страницы в одной таблице», есть 2 варианта. Первый вариант - дублировать записи в таблице страниц, чтобы вы могли извлечь некоторые биты виртуального адреса и использовать их в качестве индекса в таблице; что (кроме незначительных различий в способах управления TLB - например, автоматическое обнаружение смежных трансляций по сравнению с указанием вручную) фактически идентично тому, что вообще не беспокоит; но есть некоторые процессоры (думаю, ARM), которые делают это.
Другой альтернативой является поиск нескольких записей в таблице страниц, чтобы найти нужную запись, где стоимость поиска снижает производительность. Я не знаю ни одного процессора, поддерживающего это - производительность слишком важна.