Тема 13: Управління сторінковою пам’яттю.
Стратегії управління сторінковою пам'яттю
Програмне забезпечення підсистеми управління пам'яттю пов'язане з реалізацією наступних стратегій:
Стратегія вибірки (fetch policy) - в який момент слід переписати сторінку з вторинної пам'яті в первинну. Існує два основні варіанти вибірки - за запитом і з попередженням. Алгоритм вибірки за запитом вступає в дію в той момент, коли процес звертається до відсутньої сторінки, вміст якої знаходиться на диску. Його реалізація полягає в завантаженні сторінки з диска у вільну фізичну сторінку і корекції відповідного запису таблиці сторінок.
Алгоритм вибірки з попередженням здійснює випереджаюче читання, тобто окрім сторінки, що викликала виняткову ситуацію, в пам'ять також завантажується декілька сторінок, що оточують її (зазвичай сусідні сторінки розташовуються в зовнішній пам'яті послідовно і можуть бути лічені за одне звернення до диска). Такий алгоритм покликаний зменшити накладні витрати, пов'язані з великою кількістю виняткових ситуацій, що виникають при роботі із значними об'ємами даних або коди; крім того, оптимізується робота з диском.
Стратегія розміщення (placement policy) - в яку ділянку первинної пам'яті помістити сторінку, що поступає. У системах із сторінковою організацією все просто - в будь-який вільний сторінковий кадр. У разі систем з сегментною організацією необхідна стратегія, аналогічна стратегії з динамічним розподілом.
Стратегія заміщення (replacement policy) - яку сторінку потрібно виштовхнути в зовнішню пам'ять, щоб звільнити місце в оперативній пам'яті. Розумна стратегія заміщення, реалізована у відповідному алгоритмі заміщення сторінок, дозволяє зберігати в пам'яті найнеобхіднішу інформацію і тим самим понизити частоту сторінкових порушень. Заміщення повинне відбуватися з урахуванням виділеного кожному процесу кількості кадрів. Крім того, потрібно вирішити, чи повинна сторінка, що заміщається, належати процесу, який ініціював заміщення, або вона має бути вибрана серед всіх кадрів основної пам'яті.
Алгоритми заміщення сторінок
Отже, найбільш відповідальною дією менеджера пам'яті є виділення кадру оперативній пам'яті для розміщення в ній віртуальної сторінки, що знаходиться в зовнішній пам'яті. Нагадаємо, що ми розглядаємо ситуацію, коли розмір віртуальної пам'яті для кожного процесу може істотно перевершувати розмір основної пам'яті. Це означає, що при виділенні сторінки основній пам'яті з великою вірогідністю не вдасться знайти вільний сторінковий кадр. В цьому випадку операційна система відповідно до закладених в неї критеріїв винна:
знайти деяку зайняту сторінку основної пам'яті;
перемістити у разі потреби її вміст в зовнішню пам'ять;
переписати в цей сторінковий кадр вміст потрібної віртуальної сторінки із зовнішньої пам'яті;
належним чином модифікувати необхідний елемент відповідної таблиці сторінок;
продовжити виконання процесу, якому ця віртуальна сторінка знадобилася.
Відмітимо, що при заміщенні доводиться двічі передавати сторінку між основною і вторинною пам'яттю. Процес заміщення може бути оптимізований за рахунок використання біта модифікації (один з атрибутів сторінки в таблиці сторінок). Біт модифікації встановлюється комп'ютером, якщо хоч би один байт був записаний на сторінку. При виборі кандидата на заміщення перевіряється біт модифікації. Якщо біт не встановлений, немає необхідності переписувати дану сторінку на диск, її копія на диску вже є. Подібний метод також застосовується до read-only-страницам, вони ніколи не модифікуються. Ця схема зменшує час обробки page fault.
Існує велика кількість різноманітних алгоритмів заміщення сторінок. Всі вони діляться на локальних і глобальних. Локальні алгоритми, на відміну від глобальних, розподіляють фіксоване або таке, що динамічно настроюється число сторінок для кожного процесу. Коли процес витратить всі призначені йому сторінки, система видалятиме з фізичної пам'яті одну з його сторінок, а не із сторінок інших процесів. Глобальний же алгоритм заміщення у разі виникнення виняткової ситуації задовольниться звільненням будь-якої фізичної сторінки, незалежно від того, якому процесу вона належала.
Глобальні алгоритми мають ряд недоліків. По-перше, вони роблять одні процеси чутливими до поведінки інших процесів. Наприклад, якщо один процес в системі одночасно використовує велику кількість сторінок пам'яті, то решта всіх застосувань в результаті відчуватиме сильне уповільнення через нестачу кадрів пам'яті для своєї роботи. По-друге, некоректно працююче застосування може підірвати роботу всієї системи (якщо, звичайно, в системі не передбачено обмеження на розмір пам'яті, що виділяється процесу), намагаючись захопити більше пам'яті. Тому в багатозадачній системі іноді доводиться використовувати складніші локальні алгоритми. Застосування локальних алгоритмів вимагає зберігання в операційній системі списку фізичних кадрів, виділених кожному процесу. Цей список сторінок іноді називають резидентним безліччю процесу. У одному з наступних розділів розглянутий варіант алгоритму підкачки, заснований на приведенні резидентної множини у відповідність так званому робочому набору процесу.
Ефективність алгоритму зазвичай оцінюється на конкретній послідовності посилань до пам'яті, для якої підраховується число тих, що виникають page faults. Ця послідовність називається рядком звернень (reference string). Ми можемо генерувати рядок звернень штучним чином за допомогою датчика випадкових чисел або трасуючи конкретну систему. Останній метод дають дуже багато посилання, для зменшення числа яких можна зробити дві речі:
для конкретного розміру сторінок можна запам'ятовувати тільки їх номери, а не адреси, на які йде посилання;
декілька підряд посилань, що йдуть, на одну сторінку можна фіксувати один раз.
Як вже мовилося, більшість процесорів мають прості апаратні засоби, що дозволяють збирати деяку статистику звернень до пам'яті. Ці засоби зазвичай включають два спеціальні прапори на кожен елемент таблиці сторінок. Прапор посилання (reference битий) автоматично встановлюється, коли відбувається будь-яке звернення до цієї сторінки, а вже розглянутий вище прапор зміни (modify битий) встановлюється, якщо проводиться запис в цю сторінку. Операційна система періодично перевіряє установку таких прапорів, для того, щоб виділити активно використовувані сторінки, після чого значення цих прапорів скидаються.
Розглянемо ряд алгоритмів заміщення сторінок.
Алгоритм FIFO. Виштовхування першої сторінки
Простий алгоритм. Кожній сторінці привласнюється тимчасова мітка. Реалізується це просто створенням черги сторінок, в кінець якої сторінки потрапляють, коли завантажуються у фізичну пам'ять, а з початку беруться, коли потрібно звільнити пам'ять. Для заміщення вибирається стара сторінка. На жаль, ця стратегія з достатньою вірогідністю приводитиме до заміщення активно використовуваних сторінок, наприклад сторінок коди текстового процесора при редагуванні файлу. Відмітимо, що при заміщенні активних сторінок все працює коректно, але page fault відбувається негайно.
Аномалія Біледі (Belady)
На перший погляд здається очевидним, що чим більше в пам'яті сторінкових кадрів, тим рідше матимуть місце page faults. Дивно, але це не завжди так. Як встановив Біледі з колегами, певні послідовності звернень до сторінок насправді приводять до збільшення числа сторінкових порушень при збільшенні кадрів, виділених процесу. Це явище носить назва "Аномалії Біледі" або "аномалії FIFO".
Система з трьома кадрами (9 faults) виявляється продуктивнішою, ніж з чотирма кадрами (10 faults), для рядка звернень до пам'яті 012301401234 при виборі стратегії FIFO.
Рис. 12.1. Аномалія Біледі: (a) - FIFO з трьома сторінковими кадрами; (b) - FIFO з чотирма сторінковими кадрами
Аномалію Біледі слід рахувати швидше курйозом, чим чинником, що вимагає серйозного відношення, який ілюструє складність ОС, де інтуїтивний підхід не завжди прийнятний.
Оптимальний алгоритм (OPT)
Одним з наслідків відкриття аномалії Біледі став пошук оптимального алгоритму, який при заданому рядку звернень мав би мінімальну частоту page faults серед всіх інших алгоритмів. Такий алгоритм був знайдений. Він простий: заміщай сторінку, яка не використовуватиметься протягом найтривалішого періоду часу.
Кожна сторінка має бути помічена числом інструкцій, які будуть виконані, перш ніж на цю сторінку буде зроблено перше посилання. Виштовхуватися повинна сторінка, для якої це число найбільше.
Цей алгоритм легко описати, але реалізувати неможливо. ОС не знає, до якої сторінки буде наступне звернення. (Раніше такі проблеми виникали при плануванні процесів - алгоритм SJF).
Зате ми можемо зробити вивід, що для того, щоб алгоритм заміщення був максимально близький до ідеального алгоритму, система винна якомога точніше передбачати звернення процесів до пам'яті. Даний алгоритм застосовується для оцінки якості алгоритмів, що реалізовуються.
Виштовхування сторінки, що найдовше не використовувалась. Алгоритм LRU.
Одним з наближень до алгоритму OPT є алгоритм, витікаючий з евристичного правила, що недавнє минуле - хороший орієнтир для прогнозування найближчого майбутнього.
Ключова відмінність між FIFO і оптимальним алгоритмом полягає в тому, що один дивиться назад, а інший вперед. Якщо використовувати минуле для апроксимації майбутнього, має сенс заміщати сторінку, яка не використовувалася протягом найдовшого часу. Такий підхід називається least recently used алгоритм (LRU). Робота алгоритму проілюстрована на мал. мал. 10.2. Порівнюючи мал. 10.1 b і 10.2, можна побачити, що використання LRU алгоритму дозволяє скоротити кількість сторінкових порушень.
Рис. 12.2. Приклад роботи алгоритму LRU
LRU - хороший, але важкореалізований алгоритм. Необхідно мати зв'язаний список всіх сторінок в пам'яті, на початку якого будуть зберігається недавно використані сторінки. Причому цей список повинен оновлюватися при кожному зверненні до пам'яті. Багато часу потрібно і на пошук сторінок в такому списку.
У [Таненбаум, 2002] розглянутий варіант реалізації алгоритму LRU із спеціальним 64-бітовим покажчиком, який автоматично збільшується на одиницю після виконання кожної інструкції, а в таблиці сторінок є відповідне поле, в яке заноситься значення покажчика при кожному посиланні на сторінку. При виникненні page fault вивантажується сторінка з найменшим значенням цього поля.
Як оптимальний алгоритм, так і LRU не страждають від аномалії Біледі. Існує клас алгоритмів, для яких при одному і тому ж рядку звернень безліч сторінок в пам'яті для n кадрів завжди є підмножиною сторінок для n+1 кадру. Ці алгоритми не проявляють аномалії Біледі і називаються стековими (stack) алгоритмами.
Виштовхування рідко використовуваної сторінки. Алгоритм NFU
Оскільки більшість сучасних процесорів не надають відповідної апаратної підтримки для реалізації алгоритму LRU, хотілося б мати алгоритм, достатньо близький до LRU, але що не вимагає спеціальної підтримки.
Програмна реалізація алгоритму, близького до LRU, - алгоритм NFU(Not Frequently Used).
Для нього потрібні програмні лічильники, поодинці на кожну сторінку, які спочатку дорівнюють нулю. При кожному перериванні за часом (а не після кожної інструкції) операційна система сканує всі сторінки в пам'яті і у кожної сторінки зі встановленим прапором звернення збільшує на одиницю значення лічильника, а прапор звернення скидає.
Таким чином, кандидатом на звільнення виявляється сторінка з найменшим значенням лічильника, як сторінка, до якої найрідше зверталися. Головний недолік алгоритму NFU полягає в тому, що він нічого не забуває. Наприклад, сторінка, до якої дуже часто зверталися протягом деякого часу, а потім звертатися перестали, все одно не буде видалена з пам'яті, тому що її лічильник містить велику величину. Наприклад, в багатопрохідних компіляторах сторінки, які активно використовувалися під час першого проходу, можуть надовго зберегти великі значення лічильника, заважаючи завантаженню корисних надалі сторінок.
На щастя, можлива невелика модифікація алгоритму, яка дозволяє йому "забувати". Достатньо, щоб при кожному перериванні за часом вміст лічильника зрушувався управо на 1 битий, а вже потім проводилося б його збільшення для сторінок зі встановленим прапором звернення.
Іншим, вже стійкішим недоліком алгоритму є тривалість процесу сканування таблиць сторінок.
Інші алгоритми
Для повноти картини можна згадати ще декілька алгоритмів.
Наприклад, алгоритм Second-Chance - модифікація алгоритму FIFO, яка дозволяє уникнути втрати часто використовуваних сторінок за допомогою аналізу прапора звернень (біта посилання) для найстарішої сторінки. Якщо прапор встановлений, то сторінка, на відміну від алгоритму FIFO, не виштовхується, а її прапор скидається, і сторінка переноситься в кінець черги. Якщо спочатку прапори звернень були встановлені для всіх сторінок (на всі сторінки посилалися), алгоритм Second-Chance перетворюється на алгоритм FIFO. Даний алгоритм використовувався в Multics і BSD Unix.
У комп'ютері Macintosh використаний алгоритм NRU (Not Recently-Used), де страница-"жертва" вибирається на основі аналізу бітів модифікації і посилання. Цікаві стратегії, засновані на буферизації сторінок, реалізовані в VAX/VMS і Mach.
Є також і багато інших алгоритмів заміщення. Об'єм цього курсу не дозволяє розглянути їх детально. Докладний опис різних алгоритмів заміщення можна знайти в монографіях [Дейтел, 1987], [Цикрітіс, 1977], [Таненбаум, 2002] і ін.
Управління кількістю сторінок, виділеною процесу. Модель робочої множини
У стратегіях заміщення, розглянутих в попередньому розділі, простежується припущення про те, що кількість кадрів, що належать процесу, не можна збільшити. Це приводить до необхідності виштовхування сторінки. Розглянемо більш загальний підхід, що базується на концепції робочої множини, сформульованою Деннінгом [Denning, 1996].
Отже, що робити, якщо у розпорядженні процесу є недостатнє число кадрів? Чи потрібно його припинити із звільненням всіх кадрів? Що слід розуміти під достатньою кількістю кадрів?
Трешинг (Thrashing)
Хоча теоретично можливо зменшити число кадрів процесу до мінімуму, існує якесь число активно використовуваних сторінок, без якого процес часто генерує page faults. Висока частота сторінкових порушень називається трешинг (thrashing, іноді уживається російський термін "пробуксувала", див. мал. 10.3). Процес знаходиться в змозі трешинга, якщо при його роботі більше часу йде на підкачку сторінок, ніж на виконання команд. Такого роду критична ситуація виникає незалежно від конкретних алгоритмів заміщення.
Рис. 12.3. Частота page faults залежно від кількості кадрів, виділених процесу
Часто результатом трешинга є зниження продуктивності обчислювальної системи. Одін з небажаних сценаріїв розвитку подій може виглядати таким чином. При глобальному алгоритмі заміщення процес, якому не вистачає кадрів, починає відбирати кадри у інших процесів, які у свою чергу починають займатися тим же. В результаті всі процеси потрапляють в чергу запитів до пристрою вторинної пам'яті (знаходяться в стані очікування), а черга процесів в стані готовності пустіє. Завантаження процесора знижується. Операційна система реагує на це збільшенням ступеня мультипрограмування, що приводить до ще більшого трешингу і подальшого зниження завантаження процесора. Таким чином, пропускна спроможність системи падає із-за трешинга.
Ефект трешинга, що виникає при використанні глобальних алгоритмів, може бути обмежений за рахунок застосування локальних алгоритмів заміщення. При локальних алгоритмах заміщення якщо навіть один з процесів потрапив в трешинг, це не позначається на інших процесах. Проте він багато часу проводить в черзі до пристрою вивантаження, утрудняючи підкачку сторінок решти процесів.
Критична ситуація типу трешинга виникає незалежно від конкретних алгоритмів заміщення. Єдиним алгоритмом, що теоретично гарантує відсутність трешинга, є розглянутий вище оптимальний алгоритм, що не реалізовується на практиці.
Отже, трешинг - це висока частота сторінкових порушень. Hеобходимо її контролювати. Коли вона висока, процес потребує кадрів. Можна, встановлюючи бажану частоту page faults, регулювати розмір процесу, додаючи або віднімаючи у нього кадри. Може виявитися доцільним вивантажити процес цілком. Кадри, що звільнилися, виділяються іншим процесам з високою частотою page faults.
Для запобігання трешинга потрібно виділяти процесу стільки кадрів, скільки йому потрібно. Hо як дізнатися, скільки йому потрібно? Необхідно спробувати з'ясувати, як багато кадрів процес реально використовує. Для вирішення цього завдання Деннінг використовував модель робочої множини, яка заснована на застосуванні принципу локальності.
Модель робочої множини
Розглянемо поведінку реальних процесів.
Процеси починають працювати, не маючи в пам'яті необхідних сторінок. В результаті при виконанні першої ж машинної інструкції виникає page fault, що вимагає підкачки порції коди. Наступний page fault відбувається при локалізації глобальних змінних і ще один - при виділенні пам'яті для стека. Після того, як процес зібрав велику частину необхідних йому сторінок, page faults виникають рідко.
Таким чином, існує набір сторінок (P1, P2 ... Pn), що активно використовуються разом, який дозволяє процесу у момент часу t протягом деякого періоду T продуктивно працювати, уникаючи великої кількості page faults. Цей набір сторінок називається робочим безліччю W(t,T) (working set) процесу. Число сторінок в робочій множині визначається параметром Т, є неубутною функцією T і відносно невелико. Іноді T називають розміром вікна робочої множини, через яку ведеться спостереження за процесом (див. мал. 10.4).
Рис. 12.4. Приклад робочої множини процесу
Легко написати тестову програму, яка систематично працює з великим діапазоном адрес, але, на щастя, більшість реальних процесів не ведуть себе так само, а проявляють властивість локальності. Протягом будь-якої фази обчислень процес працює з невеликою кількістю сторінок.
Коли процес виконується, він рухається від однієї робочої множини до іншого. Програма зазвичай складається з декількох робочих множин, які можуть перекриватися. Hапример, коли викликана процедура, вона визначає нову робочу множину, що складається із сторінок, що містять інструкції процедури, її локальні і глобальні змінні. Після її завершення процес покидає ця робоча множина, але може повернутися до нього при новому виклику процедури. Таким чином, робоча множина визначається кодом і даними програми. Якщо процесу виділяти менше кадрів, чим йому вимагається для підтримки робочої множини, він знаходитиметься в змозі трешинга.
Принцип локальності посилань перешкоджає частим змінам робочих наборів процесів. Формально це можна виразити таким чином. Якщо в період часу програма зверталася до сторінок W(t,T), то при належному виборі T з великою вірогідністю ця програма звертатиметься до тих же сторінок в період часу (t, t+T). Іншими словами, принцип локальності стверджує, що якщо не дуже далеко заглядати в майбутнє, то можна достатньо точно його прогнозувати виходячи з минулого. Зрозуміло, що з часом робочий набір процесу може змінюватися (як по складу сторінок, так і по їх числу).
Найбільш важлива властивість робочої множини - його розмір. ОС повинна виділити кожному процесу достатнє число кадрів, щоб помістилася його робоча множина. Якщо кадри ще залишилися, то може бути ініційований інший процес. Якщо робоча безліч процесів не поміщається в пам'ять і починається трешинг, то один з процесів можна вивантажити на диск.
Вирішення про розміщення процесів в пам'яті винне, отже, базуватися на розмірі його робочої множини. Для процесів, що вперше ініціюються, це рішення може бути ухвалене евристично. Під час роботи процесу система повинна уміти визначати: розширює процес своя робоча множина або переміщається на нову робочу множину. Якщо до складу атрибутів сторінки включити час останнього використання ti (для сторінки з номером i), то приналежність i-й сторінки до робочого набору, визначуваного параметром T у момент часу t виражатиметься нерівністю: t-T < ti < t. Алгоритм виштовхування сторінок WSClock, що використовує інформацію про робочий набір процесу, описаний в [Таненбаум, 2002].
Інший спосіб реалізації даного підходу може бути заснований на відстежуванні кількості сторінкових порушень, що викликаються процесом. Якщо процес часто генерує page faults і пам'ять не дуже заповнена, то система може збільшити число виділених йому кадрів. Якщо ж процес не викликає виняткових ситуацій протягом деякого часу і рівень генерації нижче якогось порогу, то число кадрів процесу може бути урізане. Цей спосіб регулює лише розмір безлічі сторінок, що належать процесу, і має бути доповнений якою-небудь стратегією заміщення сторінок. Не дивлячись на те що система при цьому може пробуксовывать в моменти переходу від однієї робочої множини до іншого, пропоноване рішення в змозі забезпечити якнайкращу продуктивність для кожного процесу, не вимагаючи ніякого додаткового налаштування системи.
Сторінкові демони
Підсистема віртуальної пам'яті працює продуктивно за наявності резерву вільних сторінкових кадрів. Алгоритми, що забезпечують підтримку системи в стані відсутності трешинга, реалізовані у складі фонових процесів (їх часто називають демонами або сервісами), які періодично "прокидаються" і інспектують стан пам'яті. Якщо вільні кадрів виявляється мало, вони можуть змінити стратегію заміщення. Їх завдання - підтримувати систему в стані якнайкращої продуктивності.
Прикладом такого роду процесу може бути фоновий процес - складальник сторінок, що реалізовує полегшений варіант алгоритму відкачування, заснований на використанні робочого набору і вживаний в багатьох клонах ОС Unix (див., наприклад[Bach, 1986]). Даний демон проводить відкачування сторінок, що не входять в робочі набори процесів. Він починає активно працювати, коли кількість сторінок в списку вільних сторінок досягає встановленого нижнього порогу, і намагається виштовхувати сторінки відповідно до власної стратегії.
Але якщо виникає вимога сторінки в умовах, коли список вільних сторінок порожній, то починає працювати механізм свопінгу, оскільки просте відняття сторінки у будь-якого процесу (включаючи той, який зажадав би сторінку) потенційно вело б до ситуації thrashing, і руйнувало б робочий набір деякого процесу. Будь-який процес, що зажадав сторінку не зі свого поточного робочого набору, стає в чергу на вивантаження з розрахунку на те, що після завершення вивантаження хоч би одного з процесів вільної пам'яті вже може бути досить.
У ОС Windows 2000 аналогічну роль грає менеджер балансного набору (Working set manager), який викликається раз в секунду або тоді, коли розмір вільної пам'яті опускається нижче певної межі, і відповідає за сумарну політику управління пам'яттю і підтримку робочих множин.
Окремі аспекти функціонування менеджера пам'яті
Коректна робота менеджера пам'яті окрім принципових питань, пов'язаних з вибором абстрактної моделі віртуальної пам'яті і її апаратною підтримкою, забезпечується також безліччю нюансів і дрібних деталей. Як приклад такого роду компоненту розглянемо детальніше локалізацію сторінок в пам'яті, яка застосовується в тих випадках, коли підтримка сторінкової системи приводить до необхідності дозволити певним сторінкам, що зберігають буфери введення-виводу, інші важливі дані і код, бути блокованими в пам'яті.
Розглянемо випадок, коли система віртуальної пам'яті може вступити в конфлікт з підсистемою введення-виводу. Наприклад, процес може запитати введення в буфер і чекати його завершення. Управління передасться іншому процесу, який може викликати page fault і, з відмінною від нуля вірогідністю, спровокувати вивантаження тієї сторінки, куди має бути здійснений введення першим процесом. Подібні ситуації потребують додаткового контролю, особливо якщо уведення-виведення реалізоване з використанням механізму прямого доступу до пам'яті (DMA). Одне з вирішень даної проблеми - вводити дані в буфер, що не витісняється, в просторі ядра, а потім копіювати їх в призначений для користувача простір.
Друге рішення - локалізувати сторінки в пам'яті, використовуючи спеціальний біт локалізації, що входить до складу атрибутів сторінки. Локалізована сторінка заміщенню не підлягає. Біт локалізації скидається після завершення операції введення-виводу.
Інше використання біта локалізації може мати місце і при нормальному заміщенні сторінок. Розглянемо наступний ланцюг подій. Низькопріоритетний процес після тривалого очікування отримав в своє розпорядження процесор і підкачав з диска потрібну йому сторінку. Якщо він відразу після цього буде витиснений високопріоритетним процесом, останній може легко замістити знов підкачану сторінку низькопріоритетного, оскільки на неї не було посилань. Має сенс знов завантажені сторінки позначати бітом локалізації до першого посилання, інакше низькопріоритетний процес так і не почне працювати.
Використання біта локалізації може бути небезпечним, якщо забути його відключити. Якщо така ситуація має місце, сторінка стає невживаною. SUNOS вирішує використання даного біта як підказку, яку можна ігнорувати, коли пул вільних кадрів стає дуже маленьким.
Іншим важливим застосуванням локалізації є її використання в системах м'якого реального часу. Розглянемо процес або нитку реального часу. Взагалі кажучи, віртуальна пам'ять - антитеза обчислень реального часу, оскільки дає непередбачувані затримки при підкачці сторінок. Тому системи реального часу майже не використовують віртуальну пам'ять. ОС Solaris підтримує як реальний час, так і розділення часу. Для вирішення проблеми page faults, Solaris дозволяє процесам повідомляти систему, які сторінки важливі для процесу, і локалізувати їх в пам'яті. В результаті можливе виконання процесу, що реалізовує завдання реального часу, що містить локалізовані сторінки, де тимчасові затримки сторінкової системи будуть мінімізовані.
Окрім системи локалізації сторінок, є і інші цікаві проблеми, що виникають в процесі управління пам'яттю. Так, наприклад, буває непросто здійснити повторне виконання інструкції, що викликала page fault. Представляють інтерес і алгоритми відкладеного виділення пам'яті (копіювання при записі і ін.). Обмежений об'єм даного курсу не дозволяє розглянути їх детальніше.
Висновок
Описана система управління пам'яттю є сукупністю програмно-технічних засобів, що забезпечують продуктивне функціонування сучасних комп'ютерів. Успіх реалізації тієї частини ОС, яка відноситься до управління віртуальною пам'яттю, визначається близькістю архітектури апаратних засобів, що підтримують віртуальну пам'ять, до абстрактної моделі віртуальної пам'яті ОС. Справедливості ради відмітимо, що в переважній більшості сучасних комп'ютерів апаратура виконує функції, потреби моделі ОС, що істотно перевищують, так що створення апаратно-залежної частини підсистеми управління віртуальною пам'яттю ОС в більшості випадків немає надмірно складною задачею.