6.10: Апаратна підтримка віртуальної пам'яті
- Page ID
- 34529
Як розглянуто в розділі під назвою «TLB», апаратне забезпечення процесора забезпечує таблицю пошуку, яка пов'язує віртуальні адреси з фізичними адресами. Кожна архітектура процесора визначає різні способи управління TLB з різними перевагами і недоліками. Частина процесора, яка займається віртуальною пам'яттю, зазвичай називається блоком управління пам'яттю або MMU.
ХХХ
Itanium MMU надає безліч цікавих функцій для роботи операційної системи з віртуальною пам'яттю.
розділ під назвою «Промивання TLB» ввів концепцію ідентифікатора адресного простору для зменшення накладних витрат на промивання TLB при перемиканні контексту. Однак програмісти часто використовують потоки, щоб контексти виконання ділитися адресним простором. Кожен потік має однаковий ASID і, отже, розділяє записи TLB, що призводить до підвищення продуктивності. Однак єдиний ASID заважає TLB забезпечити захист; обмін стає підходом «все або нічого». Щоб поділитися навіть кількома байтами, потоки повинні відмовитися від будь-якого захисту один від одного (див. Також розділ під назвою «Захист»).
Itanium MMU розглядає ці проблеми і забезпечує можливість спільного використання адресного простору (а отже, і записів перекладу) з набагато меншою деталізацією, зберігаючи при цьому захист в апаратному забезпеченні. Itanium розділяє 64-бітний адресний простір на 8 областей, як показано на малюнку 6.7, «Ілюстрація областей Itanium та клавіш захисту». Кожен процес має вісім 24-бітових регістрів регіону як частину свого стану, кожен з яких містить ідентифікатор регіону (RID) для кожної з восьми областей адресного простору процесу. Переклади TLB позначаються RID і, таким чином, будуть збігатися лише в тому випадку, якщо процес також містить цей RID, як показано на малюнку 6.8, «Ілюстрація перекладу Itanium TLB».
Крім цього, три верхні біти (біти регіону) не враховуються в перекладі віртуальних адрес. Отже, якщо два процеси поділяють RID (тобто мають однакове значення в одному з регістрів регіону), то вони мають згладжене уявлення про цю область. Наприклад, якщо Process-A тримає RID 0x100 в регістрі-регістрі 3, а процес-B тримає той самий RID 0x100 в регістрі 5, то process-A, область 3 псевдонім до процесу-B, область 5. Цей обмежений обмін означає, що обидва процеси отримують переваги спільних записів TLB без необхідності надавати доступ до всього адресного простору.
Щоб забезпечити ще більш дрібнозернистий обмін, кожен запис TLB на Itanium також позначений ключем захисту. Кожен процес має додаткову кількість регістрів ключів захисту під управлінням операційної системи.
Коли потрібно поділитися серією сторінок (наприклад, код для спільної системної бібліотеки), кожна сторінка позначається унікальним ключем, а ОС надає будь-яким процесам, дозволеним для доступу до сторінок цього ключа. Коли сторінка посилається, TLB перевірить ключ, пов'язаний із записом перекладу, щодо ключів, які процес містить у своїх регістрах ключів захисту, дозволяючи доступ, якщо ключ присутній, або іншим чином викликаючи несправність захисту операційної системи.
Ключ також може застосовувати дозволи; наприклад, один процес може мати ключ, який надає права на запис, а інший може мати ключ лише для читання. Це дозволяє обмінюватися записами перекладу в набагато ширшому діапазоні ситуацій з деталізацією аж до односторінкового рівня, що призводить до значних потенційних покращень продуктивності TLB.
Перемикання контексту на ОС при вирішенні пропуску TLB додає значні накладні витрати на шлях обробки несправностей. Для боротьби з цим Itanium дозволяє використовувати вбудоване обладнання для читання таблиці сторінок та автоматичного завантаження віртуально-фізичних перекладів у TLB. Апаратна таблиця сторінок (HPW) дозволяє уникнути дорогого переходу на ОС, але вимагає, щоб переклади були у фіксованому форматі, придатному для розуміння обладнання.
Itanium HPW згадується в документації Intel як практично хешований настільний Уокер або VHPT walker, з причин, які повинні стати зрозумілими. Itanium надає розробникам можливість двох взаємовиключних реалізацій HPW; одна заснована на віртуальній лінійній таблиці сторінок, а інша на основі хеш-таблиці.
Слід зазначити, що можна працювати без апаратної таблиці сторінок; в цьому випадку кожен промах TLB вирішується ОС і процесор стає програмно завантаженою архітектурою. Однак вплив на продуктивність відключення HPW настільки значний, що дуже малоймовірно, що будь-яка вигода може бути отримана від цього.
Реалізація віртуальної лінійної сторінки-таблиці згадується в документації як короткий формат практично хешованої сторінки-таблиці (SF-VHPT). Це модель HPW за замовчуванням, яка використовується Linux на Itanium.
Звичайним рішенням є багаторівнева або ієрархічна таблиця сторінок, де біти, що містять віртуальний номер сторінки, використовуються в якості індексу на проміжні рівні сторінки-таблиці (див. Розділ «Трирівнева таблиця сторінок»). Порожні області віртуального адресного простору просто не існують в ієрархічній таблиці сторінок. Порівняно з лінійною таблицею сторінок, для (реалістичного) випадку щільно кластеризованого та рідкозаповненого адресного простору відносно мало місця витрачається на накладні витрати. Основним недоліком є кілька посилань на пам'ять, необхідні для пошуку.
При 64-розрядному адресному просторі навіть лінійна таблиця 512 ~ ГіБ, визначена в розділі «Переклад віртуальних адрес», займає лише 0,003% від наявних 16-ексабайт. Таким чином, віртуальна лінійна таблиця сторінок (VLPT) може бути створена в суміжній області віртуального адресного простору.
Так само, як і для фізично лінійної таблиці сторінок, на TLB пропустити апаратне забезпечення використовує віртуальний номер сторінки для зміщення від бази сторінки-таблиці. Якщо цей запис дійсний, переклад читається і вставляється безпосередньо в TLB. Однак, з VLPT адреса запису перекладу сама по собі є віртуальною адресою, і, отже, існує ймовірність того, що віртуальна сторінка, в якій вона знаходиться, відсутня в TLB. В цьому випадку вкладена несправність піднімається на операційну систему. Програмне забезпечення має виправити цю несправність, зіставляючи сторінку, що містить запис перекладу, у VLPT.
Цей процес можна зробити досить прямо, якщо операційна система зберігає ієрархічну таблицю сторінок. Сторінка листа ієрархічної таблиці сторінок містить записи перекладу для практично суміжної області адрес і, таким чином, може бути зіставлена TLB для створення VLPT, як описано на малюнку 6.10, «Реалізація VHPT короткого формату Itanium».
Основна перевага VLPT виникає, коли програма робить повторний або суміжний доступ до пам'яті. Вважайте, що для прогулянки практично суміжної пам'яті перша помилка буде відображати сторінку, повну записів перекладу, у віртуальну лінійну таблицю сторінок. Подальший доступ до наступної віртуальної сторінки вимагатиме завантаження наступного запису перекладу в TLB, який тепер доступний у VLPT і таким чином завантажується дуже швидко і без виклику операційної системи. Загалом, це буде перевагою, якщо вартість початкової вкладеної несправності амортизується над наступними хітами HPW.
Основним недоліком є те, що VLPT тепер вимагає введення TLB, що спричиняє підвищення тиску TLB. Оскільки для кожного адресного простору потрібна своя таблиця сторінок, накладні витрати стають більшими, оскільки система стає більш активною. Однак будь-яке збільшення пропускної здатності TLB має бути більш ніж відновленим у менших витратах на поповнення від ефективного апаратного ходунка. Зверніть увагу, що патологічний випадок може пропустити записи page_size ÷ translation_size, викликаючи повторні вкладені помилки, але це дуже малоймовірний шаблон доступу.
Апаратний ходок очікує записи перекладу у певному форматі, як показано зліва на малюнку 6.11, «Формати запису Itanium PTE». VLPT вимагає перекладів у так званому 8-байтовому короткому форматі. Якщо операційна система має використовувати свою таблицю сторінок як резервну копію для VLPT (як на рис. 6.10, «Короткоформатна реалізація VHPT Itanium»), вона повинна використовувати цей формат перекладу. Архітектура описує обмежену кількість бітів у цьому форматі як ігноровані і, таким чином, доступні для використання програмним забезпеченням, але значна модифікація неможлива.
Лінійна таблиця сторінок ґрунтується на ідеї фіксованого розміру сторінки. Підтримка декількох розмірів сторінки є проблематичною, оскільки це означає, що переклад для певної віртуальної сторінки більше не знаходиться на постійному зміщенні. Для боротьби з цим кожна з 8-областей адресного простору (рис. 6.7, «Ілюстрація областей Itanium та клавіші захисту») має окремий VLPT, який відображає лише адреси для цього регіону. Розмір сторінки за замовчуванням може бути вказаний для кожного регіону (дійсно, з Linux HugetLB, розглянутий нижче, один регіон присвячений більшим сторінкам). Однак розміри сторінок не можуть бути змішані в межах регіону.
Використання записів TLB в спробі зменшити витрати на поповнення TLB, як це робиться з SF-VHPT, може бути або не може бути ефективним компромісом. Itanium також реалізує хешовану таблицю сторінок з потенціалом знизити накладні витрати TLB. У цій схемі процесор хешує віртуальну адресу, щоб знайти зсув в суміжну таблицю.
Раніше описану фізично лінійну таблицю сторінок можна вважати хеш-таблицею сторінок з ідеальною хеш-функцією, яка ніколи не призведе до зіткнення. Однак, як пояснювалося, це вимагає непрактичного компромісу величезних областей суміжної фізичної пам'яті. Однак обмеження вимог до пам'яті таблиці сторінок підвищує можливість зіткнень, коли дві віртуальні адреси хеширують однаковим зміщенням. Зіткнення перекладів вимагає вказівника ланцюга для побудови зв'язаного списку альтернативних можливих записів. Щоб визначити, який запис у зв'язаному списку є правильним, потрібен тег, отриманий від вхідної віртуальної адреси.
Додаткова інформація, необхідна для кожного запису перекладу, породжує монікер довгоформатний ~VHPT (LF-VHPT). Записи перекладу зростають до 32 байт, як показано на правій стороні малюнка 6.11, «Формати записів Itanium PTE».
Основна перевага такого підходу полягає в тому, що глобальна хеш-таблиця може бути закріплена одним записом TLB. Оскільки всі процеси поділяють таблицю, вона повинна масштабуватися краще, ніж SF-VHPT, де кожен процес вимагає збільшення кількості записів TLB для сторінок VLPT. Однак більші записи менш зручні для кешу; врахуйте, що ми можемо вмістити чотири 8-байтові записи короткого формату для кожного 32-байтового довгоформатного запису. Однак дуже великі кеші на процесорі Itanium можуть допомогти пом'якшити цей вплив.
Однією з переваг SF-VHPT є те, що операційна система може зберігати переклади в ієрархічній таблиці сторінок і, поки підтримується формат апаратного перекладу, може відображати листові сторінки безпосередньо на VLPT. З LF-VHPT ОС повинна або використовувати хеш-таблицю як основне джерело записів перекладу, або іншим чином зберігати хеш-таблицю як кеш власної інформації перекладу. Зберігання хеш-таблиці LF-VHPT як кешу є дещо неоптимальним через збільшення накладних витрат на час критичних шляхів несправностей, однак переваги отримують від таблиці, що вимагає лише одного запису TLB.