Технологii вiртуалiзацii: вчора, сьогоднi, завтра
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
она не протрималася, оскiльки, як легко здогадатися, особливою гнучкiстю у використаннi не вiдрiзняСФться. Як ми з самого початку нарiжемо память скибочками, - так воно в майбутньому i залишиться: видiлимо занадто багато - якiсь областi залишаться невикористаними i простоюють; видiлимо занадто мало - не зможемо в потрiбний момент збiльшити цей обсяг. Чи памятають ще програмiсти старi добрi DOS-Овские середовища розробки вiд Borland, де в опцiях компiлятора вказувалася модель памятi, в якiй визначався розмiр i кiлькiсть використовуваних у програмi сегментiв? РЖ чи памятають користувачi чудову утiлiтку mem i знамените Not enough memory, якими так радували око користувача раннi персоналки?
Одним словом, навiть у тi часи iснували кращi рiшення, i в наступному, першому по-справжньому сучасному поколiннi x86-х процесорiв (80386) слiдом за процесорами Motorola i мейнфреймах зявилася основа будь-яких сучасних багатозадачних ОС - вiртуальна память. Про вдалiсть цiСФi розробки говорить хоча б те, що аж до переходу до 64-бiтним роздiлами iнструкцiй ядро будь-яких x86 в точностi вiдповiдало стандарту IA-32 (Intel Architecture for 32-bit), введеному Intel для i386 (так що, в принципi, на трешка повиннi працювати будь-якi 32-бiтовi програми, не задiюються занадто сучасних функцiй).
Вiртуальна память (схема 3) - це логiчний розвиток iдеi сегментованоi памятi, коли ми переходимо вiд цiлком конкретним чином перетворюються у фiзичнi лiнiйних адрес захищеного режиму x86 до абсолютно абстрактним вiртуальним адресами. Адже, за великим рахунком, для працюючоi на компютерi програми зовсiм байдуже, що за фiзичнi осередку памятi вона використовуСФ! РЗй потрiбний просто деякий дiапазон адрес, за якими вона зможе зберiгати своi данi, а що за цими цiфiркамi насправдi криСФться, iй глибоко байдуже. Головне - щоб процесор знав, як цi абстрактнi цифри (вiртуальнi адреси) переводити в цiлком конкретнi iнструкцii для контролера памятi (фiзичнi адреси).
Схема 3. Вiртуальна память
Як це робиться на практицi? Вся доступна процесору фiзична оперативна память розбиваСФться на невеликi шматочки розмiром 4 Кбайт або 4 Мбайт - сторiнки. При цьому використовуСФться та ж схема, що й при розбивцi фiзичних адрес на адреси конкретноi комiрки памятi: молодшi 12 або 22 бiт вiртуального адреси позначають змiщення цiСФi адреси вiд початку сторiнки, а старшi бiти (вiд 10 до 50) - номер сторiнки. Коли процесору потрiбно обчислити фiзичну адресу з вiртуального, вiн просто роздiляСФ вiртуальний адресу на номер сторiнки i зсув, заглядаСФ в таблицю, де для кожного номера вказанi координати початку сторiнки у фiзичнiй памятi, i додаСФ до отриманоi координатi змiщення (схема 4). Згадана табличка сторiнок називаСФться таблицею трансляцii адрес вiртуальноi памятi (або просто таблицею трансляцii), i розмiщуСФться вона у виглядi B-дерева в самiй звичайноi оперативноi памятi, що дозволяСФ створювати без великоi надлишковостi як завгодно великi швидкодiючi таблицi трансляцii. ПрацюСФ це дерево, правда (як i все, повязане з оперативною памяттю), як i ранiше не дуже швидко, i тому процесор кешуСФ ранiше певнi вiдповiдностi номер сторiнки - запис у таблицi трансляцii в спецiальному серверi - буферi трансляцii вiртуальних адрес (Translation Look -aside Buffer, TLB).
Схема 4. Робота з вiртуальною памяттю.
Деталi таблицi трансляцii
Фраза про B-дерево може прозвучати страхiтливо, але насправдi ховаСФться за цим не така вже й складна технологiя. Двiйковий номер вiртуальноi памятi, за все тiСФю ж доброю традицiСФю, розрiзаСФться на кiлька шматочкiв невеликого розмiру (по 10 бiт): наприклад, 00000000001111111111010101010101 - перетворюСФться на 0000000000 + 1111111111 + 010101010101. Перша частина адреси - 0 - це номер директорii, друга - 1023 - номер сторiнки, третя - 1365 - змiщення вiд початку сторiнки.
Що далi з цим усiм робити? У процесорi СФ спецiальний регiстр пiд назвою CR3 (Control Register # 3), в якому записуСФться вказiвник на таблицю трансляцii - фiзичну адресу, по якому в памятi розташовуСФться таблиця директорiй. Ця сама таблиця - це 1024 записи довжиною по 32 (або 64) бiта, в яких записанi фiзичнi адреси таблиць сторiнок, вiдповiдних тiй або iншiй директорii. У нас директорiя номер нуль, а тому процесор, декодуСФ вiртуальний адреса, обчислюСФ суму регiстру CR3 з нулем i отримуСФ адресу потрiбноi йому таблицi сторiнок. Ось у цiй таблицi (теж з 1024 записiв завдовжки 32 або 64 бiта) вже записанi фiзичнi адреси почав сторiнок, так що, додавши до початку таблицi сторiнок номер сторiнки (1023) - ми виходимо на запис, в якiй знаходиться фiзичну адресу початку потрiбноi нам сторiнки. ЗалишаСФться тiльки додати до нього 1365 - змiщення - i шуканий фiзичну адресу готовий. У разi 64-бiтноi органiзацii памятi рiвнiв трансляцii в цiй схемi не два, а чотири; у разi трансляцii зi сторiнками розмiром 4 Мбайт - останнiй рiвень трансляцii пропускаСФться.
Навiщо взагалi знадобилася така складна схема i чому було не можна обмежитися однiСФю таблицею трансляцii? Вся справа в розмiрi таблиць. Для 32-бiтноi адресацii памятi i сторiнок розмiром 4 Мбайт необхiдний розмiр таблицi складаСФ всього лише 4 або 8 Кбайт памятi, але для бiльш затребуваних 4 Кбайт - сторiнок, i, ще гiрше, для 64-бiтноi адресацii памятi, необхiднi розмiри таблицi виходять набагато бiльшими - вiд 4-8 Мбайт до 8 Гбайт i навiть 8 Тбайт. За часiв 386-х процесорiв навiть 4 Мбайт для таблицi трансляцii адрес однi