Віртуальна і реальна пам'ять
Мультипрограмування буде ефективним тільки у тому випадку, коли декілька процесів одночасно знаходяться в оперативній пам'яті, тоді перемикання процесів не вимагає значного переміщення даних між оперативною і зовнішньою пам'яттю. Але тоді на ОС покладається завдання розподілу оперативної пам'яті між процесами і захисту пам'яті, яка виділена процесу, від втручання іншого процесу. Таким чином, пам'ять є одним з найважливіших ресурсів системи, і від ефективності функціонування менеджера цього ресурсу в значній мірі залежать показники ефективності всієї системи в цілому.
Процесор обробляє дані, які знаходяться в оперативній пам'яті, і процеси розміщують свої коди і дані в адресному просторі, який вони розглядають, як простір оперативної пам'яті. У дуже окремих випадках програміст задає при розробці програми реальні адреси в оперативній пам'яті, в більшості ж випадків між програмістом і середовищем виконання його програми коштує той або інший апарат перетворення адрес. У загальному випадку те адресний простір, в якому пишеться програма, називається віртуальною пам'яттю, на відміну від реальної або фізичної пам'яті - в якій відбувається виконання програми (процесу). Роботу з пам'яттю можна представити у вигляді трьох функцій перетворення, які показані на Малюнку 3.1.
Ріс.3.1. Функції управління пам'яттю |
Функція іменування проводить відображення крапки з простору імен програми в простір адрес у віртуальній пам'яті, іншими словами - переводить символьні імена, використовувані програмістом, у віртуальні адреси.
Функція прив'язки проводить відображення крапки з простору віртуальних адрес в простір реальних адрес, тобто, переводить віртуальні адреси в адреси фізичних елементів пам'яті.
Функція вибірки відображає крапку з простору реальних адрес в значення, тобто, вибирає вміст пам'яті за заданою адресою.
Функція іменування реалізується здебільшого обслуговуючими програмами, ми розглядаємо її в наступному розділі. Функція вибірки завжди реалізується апаратний. У даному розділі нас цікавитиме перш за все функція прив'язки адрес. Відносно її конструктором ОС повинне бути вирішений основне питання: на якому етапі підготовки/виконання програми її виконувати?
Програміст може писати програму, відразу прив'язуючи її до свідомо відомих адрес фізичної пам'яті, - це називається програмуванням в абсолютних адресах. Таке програмування виконується в специфічних випадках, наприклад, для програм, записуваних в ПЗП. Навіть у таких випадках програміст часто користується символічними іменами, покладаючи завдання перекладу імен у фізичні адреси на транслятор. Отримана таким чином програма називається абсолютною або непереміщуваною. Вона може виконуватися тільки, будучи завантаженій за певною адресою оперативній пам'яті.
Всі прикладні програми і переважна більшість системних програм є переміщуваними. Це означає, що в програмі, підготовленій до виконання (у тому образі програми, який зберігається на зовнішній пам'яті), звернення до пам'яті налаштовані на віртуальні адреси, не прив'язані поки до адрес реальної пам'яті.
Відзначимо, що іноді віртуальною пам'яттю називають саме ці властивості апаратури обчислювальної системи і витікаючі з них можливості для процесів працювати з віртуальним адресним простором більшого розміру, чим розмір наявної в системі реальної пам'яті. Ми ж слідуємо ширшій інтерпретації [13]: віртуальна пам'ять це те адресний простір, в якому розробляється процес. Таке розуміння відповідає визначенню ОС "з погляду користувача", яке ми дали в розділі 1.4. В даному випадку ОС приховує від процесу організацію низькорівневого ресурсу (реальній пам'яті) і конструює ресурс більш високого рівня, зручніший в обігу. Така інтерпретація не бере до уваги, на якому етапі - завантаження або виконання - проводиться трансляція адрес, і чи є в системі апаратна підтримка цієї трансляції. У окремому випадку розмір віртуальної пам'яті може бути і менше реальною.
У загальному випадку проектування менеджера пам'яті у складі ОС вимагає вибору трьох основних стратегій:
- стратегії розміщення: яку область реальної пам'яті виділити процесу? як вести облік свободной/занятой реальної пам'яті?
- стратегії підкачки: коли розміщувати процес (або частина його) в реальній пам'яті?
- стратегії витіснення: якщо реальної пам'яті не вистачає для задоволення чергового запиту, то у якого процесу відібрати раніше виділений ресурс реальної пам'яті (або частина його)?
Нижче ми розглянемо способи реалізації цих стратегій для різних моделей пам'яті. Порядок розгляду відповідатиме принципу "від простого до складного" і в основному відображати також і історичний розвиток моделей пам'яті:
- фіксовані розділи - модель, що не використовує апаратну трансляцію адрес;
- односегментная віртуальна пам'ять - розвиток фіксованих розділів для апаратної трансляції адрес.
- моделі віртуальної пам'яті, що використовують розвинені засоби апаратної трансляції адрес;
- багатосегментна;
- сторінкова;
- комбінована сегментно-сторінкова.
- моделі віртуальної пам'яті, що є поверненням до простих моделей, але на більш високому рівні:
- плоска;
- одноуровневая.
Фіксовані розділи
Ця модель пам'яті застосовується в обчислювальних системах, що не мають апаратних засобів трансляції адрес. Процес завантажується в безперервну ділянку пам'яті (розділ), прив'язка адрес виконується при завантаженні. Розмір розділу рівний розміру віртуального адресного простору процесу, який, отже, не може перевищувати розміру доступної реальної пам'яті. Процес в ході свого виконання може видавати запити на виділення/звільнення пам'яті. Всі ці запити задовольняються тільки в межах віртуального адресного простору процесу, а отже - в межах виділеного йому розділу реальної пам'яті.
Прикладом ОС, що працює в такій моделі, пам'яті може бути OS/360, що нині вже не застосовується, але існувала в двох основних варіантах: MFT (з фіксованим числом завдань) і MVT (із змінним числом завдань). У першому варіанті при завантаженні ОС реальна пам'ять розбивалася на розділи оператором. Кожне завдання (процес) займало один розділ і виконувалося в нім. У другому варіанті число розділів і їх положення в пам'яті не було фіксованим. Розділ створювався у вільній ділянці пам'яті перед початком виконання завдання і мав розмір, рівний об'єму пам'яті, замовленому завданням. Створений розділ фіксувався в пам'яті на час виконання завдання, але знищувався при закінченні її виконання.
У більш загальному випадку для процесу може виділятися і декілька розділів пам'яті, причому їх виділення/звільнення може виконуватися динамічно (приклад - MS DOS). Проте, загальними завжди є наступні правила:
- розділ займає безперервну область реальної пам'яті;
- виділений розділ фіксується в реальній пам'яті;
- після виділення розділу процес працює з реальними адресами в розділі.
Завдання ефективного розподілу пам'яті (у будь-якій її моделі) зводиться перш за все до мінімізації сумарного об'єму "дірок". Нижче ми даємо визначення дірок, загальні для всіх моделей пам'яті.
Діркою називається область реальної пам'яті, яка не може бути використана. Розрізняють дірки зовнішні і внутрішні. Малюнок 3.2 ілюструє зовнішні і внутрішні дірки в системі OS/360.
Ріс.3.2. Розділи в реальній пам'яті OS/360 |
Внутрішньою діркою називається пам'ять, яка розподілена процесу, але їм не використовується. Так, на Рис 3.2.а процесу 1 виділений розділ P1, але віртуальний адресний простір процесу менше розміру розділу, простір розділу, що залишився, складає внутрішню дірку.
Зовнішньою діркою називається область реальної пам'яті, яка не розподілена ніякому процесу, але дуже мала, щоб задовольнити запит на пам'ять. На Рис 3.2.б сумарний розмір вільних областей, можливо, перевищує запит, але кожна з цих областей окремо менше запиту, тому всі ці вільні області є зовнішніми дірками.
Для управління пам'яттю формуються ті або інші структури (заголовки), що управляють, які також займають пам'ять. У деяких системах загальний об'єм заголовної пам'яті може бути дуже великим, і в таких випадках слід враховувати також і заголовні дірки - області пам'яті, які містять не використовувану в даний момент інформацію, що управляє. У системах з реальною пам'яттю заголовні дірки практично відсутні.
Дата добавления: 2016-07-27; просмотров: 2092;