Не нашел более подходящего под-форума, тут есть шанс, что кто-то знает

Рассмотрм работу MMU в 32-х разрядной системе. Допустим размер страницы 1кБ (10 бит). Пусть TLB содержит 64 записи (6 бит).

Тогда таблица TLB будет иметь 64 записи следующего вида: | Tag (16) | PhysAddr (22) |

Для преобразования VA -> PA разбиваем VA: | Tag (16) | Index (6) | Offset (10) |. По индексу находим запись в TLB и сравниваем тэги, если совпало, то формируем PA как | PhysAddr (22) | Offset (10) |.

До сюда все понятно. Но многие архитектуры выделяют несколько разных размеров страниц. Для примера сделаем "большую" страницу 2 кб (11 бит). Тогда для сохранения логики TLB нужно оставить прежним, а новые страницы будут занимать 2 записи с почти одинаковым физическим адресом.

Похоже на бред, так как от таких страниц ничего не выигрывается. Что я упускаю? Как транслировать более грубые страницы без значительного усложнения логики TLB?

У Интела в х86 преобразование в плоском режиме (Flat addressing) выполняется в два этапа.
Сначала привлекается селектор сегмента, у которого есть теневой регистр с битом гранулярности.
Этот бит определяет размер страниц при трансляции. А потом через каталог таблицы страниц.

А в вашем случае расширить поле тега и загружать бит гранулярности из дескрипторов каталога страниц.

Но это не отменит того, что первый бит поля Index (6) всегда будет содержать 0 для адресов из первой половины большой страницы и 1 для второй половины.

По-хорошему VA нужно разбивать так | Tag (15) | Index (6) | Offset (11) |, но заранее неизвестно в большой или маленькой странице адрес.

Как происходит заполнение TLB из памяти понятно, но не ясно как поможет дополнительный бит в теге если запись из TLB уже выбрали по "маленькому" индексу.

Ну все правильно.
Но кроме Tag [14:0] есть еще скрытый бит поля Tag [15], который будет определять какого размера будут поля Index и Offset.
А загружаться этот бит будет из дескриптора каталога страниц первого уровня по индексу Tag [14:0] .
Если в дескрипторе по данному индексу будет поле указывающее размер страниц 0 - обычная, 1 - большая, то при загрузке кэша TLB загрузится и скрытый
бит Tag [15], который будет управлять размером индексов страничного преобразования.
Если бит 0 то Index (6) | Offset (11) определяют 64 страницы по 2048,
Если бит 1 то Index (5) | Offset (12) определяют 32 страницы по 4096.

Index всегда 6 бит - это определяется размером TLB. Число страниц определяется как 2^(32-10) или 2^(32-11). При увеличении размера страницы уменьшается размер тэга.

Если бы выбор из TLB происходил пробеганием по всем записям, то вопросов нет, но выбор происходит прямым обращением по индексу, после чего уже не важно какой размер страницы - мы его определили самим положением индексных бит в адресе.

И так, хорошего универсального решения нет, есть набор костылей различной кривоты: http://semipublic.comp-arch.net/wiki/TLB_S...iple_Page_Sizes

http://www.google.com/patents/US5717885
http://www.google.com/patents/US5526504
Нажмите для просмотра прикрепленного файла