Чи зберігаються кешовані прогулянки по таблиці сторінок?


12

На мікропроцесорі з апаратним управлінням TLB (скажімо, Intel x86-64), якщо трапляється помилка TLB і процесор переходить на таблицю сторінок, чи це (нечиповий) доступ до пам'яті, що проходить через ієрархію кешу (L1, L2 тощо). )?


Нічого спільного з електронним дизайном. Питання буде закритим.
Леон Хеллер

8
Це питання, як працює певна фішка, тому я думаю, що це на тему.
Olin Lathrop

5
@OlinLathrop: Я згоден: я думаю, що деталі інтегральної мікросхеми низького рівня є темою.
davidcary

Я маю згоду, якщо нічого іншого, налагодження функції наших процесорів є головним кроком до отримання гідно детермінованої системи. Це наближається до одного з наших меж, але здається всередині.
Кортук

Відповіді:


8

Так, наскільки я можу сказати, на процесорах Intel x86-64, коли трапляється помилка TLB і процесор переходить на таблицю сторінок, ці доходи до пам'яті без чіпа проходять через ієрархію кешу.

Я все ще трохи нечіткий щодо кількох деталей, і я сподіваюся, що якась інша відповідь їх заповнить - чи не існує посібника з Intel чи AMD, який описує детальну інформацію про прогулянку сторінки? Я розумію, що:

  • Віртуальна адреса в деякому регістрі адрес спочатку передається швидкому TLB для перетворення на фізичну адресу - адреса в ПК передається в L1 ITLB, адреса в будь-якому іншому регістрі передається L1 DTLB .
  • Якщо цей перший пошук пропущений, є інший рівень більш повільного, великого TLB, який намагається здійснити. (Це LL TLB розділено на ITLB і DTLB також чи це єдиний кеш TLB? Чи є ще рівні TLB - L3? L4?)
  • Якщо пошук TLB повністю виходить з ладу, а ходунок VHPT x86 та x86-64 відключений, процесор сигналізує про помилку пропуску TLB, яку перехоплює ядро ​​ОС. Я розумію, що практично всі процесори, що не мають x86, роблять те саме - обробка TLB пропускається повністю в програмному забезпеченні. Якщо це ввімкнено, процесори x86 та x86-64 мають апаратну ходу VHPT, що обробляє наступні кілька кроків. (У чіпів x86 та x86-64 є один біт, який повністю вимикає VHPT, чи є багато бітів, які можуть увімкнути VHPT для деяких діапазонів адрес та відключити VHPT для інших діапазонів адрес? Де розташовані ці біти?)
  • якщо пошук TLB повністю не вдається, вихідна (вірогідно користувальницька) віртуальна адреса V1 перетворюється на V2, віртуальну адресу запису PTE таблиці сторінки, що містить фізичний номер сторінки для V1.
  • Оскільки V2 - це знову віртуальна адреса, процесор проходить через звичайний переклад віртуальної фізичної адреси, за винятком того, що він пропускає L1 і прямує до L2.
  • Обладнання шукає віртуальну адресу V2 в TLB паралельно з отриманням цього PTE з (практично індексованого) кешу L2.
  • Оскільки V2 не є адресою інструкції, вона не проходить через кеш інструкцій L1; і оскільки V2 не є адресою звичайних даних користувача, він не проходить через кеш даних L1. V2 подається спочатку в об'єднаний кеш L2 (уніфікована інструкція + дані + кеш-пам'ять PTE). Дивіться "приклад ієрархії кеша" .
  • Якщо кеш L2 (або L3 або будь-який інший практично індексований кеш) містить PTE, то VHPT витягує PTE з кеш-пам'яті та встановлює PTE для V1 в TLB, а фізичний адресу в цьому PTE використовується для перекладу оригінальну віртуальну адресу V1 у фізичну адресу оперативної пам’яті, врешті-решт витягуючи ці дані чи інструкцію цілком апаратно, без допомоги ОС.
  • Якщо всі рівні практично-індексованого кешу виходять з ладу, але цей другий пошук TLB досягає успіху для V2, то VHPT витягує PTE з фізично індексованого кешу або з основної пам'яті, встановлює PTE для V1 в TLB і фізичну адресу в цьому PTE використовується для перекладу вихідної віртуальної адреси V1 у фізичну адресу ОЗУ, зрештою витягуючи ці дані чи інструкції цілком апаратно, без допомоги ОС.
  • Якщо цей другий пошук TLB завершився невдачею, апаратний ходунок VHPT відмовляється від перекладу VHPT FAIL.
  • Коли трапляється помилка передачі VHPT, процесор потрапляє в ОС. ОС має з'ясувати, що пішло не так, і виправити речі:
  • (а) можливо, сторінка, що містить V2, наразі замінена на диск, тому ОС читає її в оперативній пам'яті і запускає невдалу інструкцію, або
  • (b) можливо, програма-баггі намагається прочитати або записати або виконати якесь недійсне місце, і ОС припиняє процес, або
  • (c) різноманітні інші хитрощі, що розробники ОС використовують для використання цього механізму для захоплення різних видів доступу - завантажте сторінку, що містить V1, яка може бути замінена на диск; різні пастки, що використовуються для налагодження нових програм; імітувати "W ^ X" на процесорах, які безпосередньо не підтримують його; підтримувати копіювати при записі; тощо.

Діаграма на сторінці 2 Томаса В. Барра, Алана Л. Кокса, Скотта Рікснера. "Кешування перекладів: Пропустіть, не ходіть (таблиця сторінок)", яка малює лінію між "Записами, збереженими в кеш-пам'яті MMU" та "Записами, збереженими в кеш-даних L2". (Це може бути корисним документом для людей, які розробляють нові процесори , що абсолютно тематично для "Дизайну електроніки").

Стефан Еранян та Девід Мосбергер. "Віртуальна пам'ять в ядрі IA-64 Linux" та Ульріх Дреппер. "Що повинен знати кожен програміст про пам'ять" (Це може бути корисним документом для людей, що пишуть операційні системи, що мають справу з таблицею сторінок IA-64, що для ED є трохи поза темою - можливо, переповнення стека " системний "тег або тег " osdev " або вікі OSDev.org було б кращим місцем для цієї теми).

Таблиця A-10 на сторінці 533 від Intel. "Посібник для розробників програмного забезпечення для архітектури Intel® 64 та IA-32" "PAGE_WALKS.CYCLES ... може натякати на те, чи більшість прогулянок сторінками задовольняються кешами чи спричиняють пропуск кеш-пам'яті L2."


Я люблю відповідь, але я, мабуть, один із багатьох, хто не має необхідного досвіду, щоб відчувати себе комфортно, даючи те, що, мабуть, заслужено піднято. Як перевіряють інші експерти, я дам відповідь, яку ви вже заробили.
Кортук

Я не вірю, що це правильно. Пуля 1 + 2 про пошук TLB правильна AFAICT, але 3 - ні. Прогулянки таблиці сторінок на x86 (або x86-64) обробляються не програмним забезпеченням (виняток застосовується, див. Далі), а апаратним забезпеченням. Тобто, коли ЦП визначить, що він не може вирішити адресу за допомогою TLB, він сам буде ходити по таблицях сторінок, починаючи з таблиці, на яку вказує реєстр CR3. Тільки якщо ця резолюція не вдалася, вона буде викликати обробку несправностей сторінки ЦП. Виняток становлять розширення з віртуалізацією, коли в певних режимах гіпервізор вирішить помилку сторінки, яка виникає у гостя.
Морті

Я не думаю, що у x86 є спосіб зробити оновлення програмного забезпечення TLB. ISA, які дозволяють обробляти м'які TLB, мають спеціальні вказівки для SW для зміни записів TLB, але я не думаю, що x86 має це інше, крім того, invlpgщоб визнати недійсним кешування TLB для певного додавача virt. Якщо на веб-переході HW не знайдено запис для цієї віртуальної адреси або дозволи доступу не дозволяють отримати доступ, ви отримуєте #PFвиняток. ОС обробляє це, оновивши таблицю сторінок (можливо, після підключення даних з диска або за допомогою копіювання під час запису), а потім відновиться, щоб несправне завантаження / зберігання почнеться повторно, і проїзд сторінки HW матиме успіх.
Пітер Кордес


4

Я схильний погоджуватися, що це належить до комп'ютерної архітектури stackexchange, а не до електроніки stackexchange, але оскільки це тут:

@davidcary правильний.

Деякі історії:

Прогулянки по таблиці Intel x86 на сторінках НЕ були кешовані аж до P5, він же Pentium. Точніше, доступ до пам’яті ходи таблиці сторінок не кешувався, обходив кеш. Оскільки більшість машин до цього часу були переписаними, вони отримували значення, що відповідають кешу. Але вони не сопіли схованки.

P6, також Pentium Pro, та AFAIK всі наступні прогулянки таблиці процесорів дозволяли отримувати доступ до кешу та використовувати значення, витягнуте з кеша. Таким чином, вони працювали з кешами для запису. (Ви, звичайно, можете розмістити таблиці сторінок у пам'яті, що не зберігається, що визначається, наприклад, MTRR. Але це велика втрата продуктивності, хоча це може бути корисно для налагодження ОС.)

До речі, цей "доступ до пам'яті ходу таблиці сторінок може отримати доступ до кешів даних" є окремим від "записи в таблиці сторінок можуть зберігатися (кешуватися) в TFB Ttranslation Lookaside Buffer)." На деяких машинах TLB називається "Кеш перекладу".

Інша пов'язана з цим проблема полягає в тому, що внутрішні вузли таблиць сторінок можуть зберігатись у кешованому режимі в ще більшій структурі даних, схожих на TLB, наприклад, кеш PDE.

Одне ключове відмінність: кеш даних є когерентним та перенесеним. Але кеші TLB і PDE не прострочені, тобто не є когерентними. Суть полягає в тому, що, оскільки таблиці сторінок можуть бути кешовані в невідповідних кешах TLB та PDE тощо, програмне забезпечення повинно явно промивати або окремі записи, або групові групи (наприклад, весь TLB), коли записи таблиці сторінок, які, можливо, були такими кешування змінено. Принаймні при зміні "небезпечним" способом, переходячи від RW-> R-> I або змінюючи адреси.

Я вважаю, що справедливо сказати, що кожного разу, коли додається новий тип не узгодженого кешування TLB, деяка ОС ламається, тому що мав неявні припущення, що цього не робиться.


Новий комп. арка. ця пропозиція розпочалася лише "3 місяці тому". Я думаю, що був раніше, який ніколи не виводив його з області51 (недостатньо послідовників?).
Пол А. Клейтон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.