Skip to main content
LibreTexts - Ukrayinska

6.7: Наслідки віртуальних адрес, сторінок і таблиць сторінок

  • Page ID
    34530
    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

    Віртуальна адресація, сторінки і таблиці сторінок - основа кожної сучасної операційної системи. Це підпирає більшість речей, для яких ми використовуємо наші системи.

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

    Згодом фізична пам'ять стає фрагментарною, а це означає, що у фізичній пам'яті є «дірки» вільного простору. Необхідність обійти ці отвори в кращому випадку дратує і стане серйозною межею для програмістів. Наприклад, якщо ви malloc 8 KiB пам'яті; вимагає підтримки двох кадрів 4 KIB, це було б величезним непереконаним, якщо ці кадри повинні бути суміжними (тобто фізично поруч один з одним). Використання віртуальних адрес це не має значення; що стосується процесу, він має 8 Кб суміжної пам'яті, навіть якщо ці сторінки підкріплені кадрами дуже далеко один від одного. Призначаючи віртуальний адресний простір кожному процесу, програміст може залишити роботу навколо фрагментації аж до операційної системи.

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

    У системі без віртуальної пам'яті кожен процес має повний доступ до всієї системної пам'яті. Це означає, що ніщо не зупиняє один процес від перезапису пам'яті інших процесів, що призводить до його збою (або, можливо, ще гірше, повернути неправильні значення, особливо якщо ця програма керує вашим банківським рахунком!)

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

    Оскільки кожна сторінка має додаткові атрибути, сторінка може бути встановлена тільки для читання, тільки для запису або мати будь-яку кількість інших цікавих властивостей. Коли процес намагається отримати доступ до сторінки, операційна система може перевірити, чи є у неї достатні дозволи, і зупинити її, якщо це не так (наприклад, запис на сторінку лише для читання).

    Системи, які використовують віртуальну пам'ять, за своєю суттю є більш стабільними, оскільки, припускаючи ідеальну операційну систему, процес може лише збоювати себе, а не всю систему (звичайно, люди пишуть операційні системи, і ми неминуче не помічаємо помилок, які все ще можуть призвести до збою цілих систем).

    Ми також можемо тепер побачити, як реалізується пам'ять підкачки. Якщо замість вказівки на область системної пам'яті, вказівник сторінки може бути змінений так, щоб він вказував на розташування на диску.

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

    Це може бути основною проблемою для пам'яті підкачки. Завантаження з жорсткого диска відбувається дуже повільно (порівняно з операціями, виконаними в пам'яті), і більшість людей будуть знайомі з сидінням перед комп'ютером, поки жорсткий диск збивається і збивається, поки система залишається невідповідною.

    Іншим, але пов'язаним процесом є карта пам'яті або mmap (від імені системного виклику). Якщо замість таблиці сторінок, що вказує на фізичну пам'ять або поміняти місцями таблицю сторінок на файл, на диску, ми говоримо, що файл mmap ed.

    Зазвичай потрібно відкрити файл на диску, щоб отримати файловий дескриптор, а потім прочитати і записати його в послідовному вигляді. Коли файл maped, він може бути доступний так само, як і системна оперативна пам'ять.

    Зазвичай кожен процес отримує власну таблицю сторінок, тому будь-яка адреса, яку він використовує, зіставляється з унікальним кадром у фізичній пам'яті. Але що робити, якщо операційна система вказує дві сторінки таблиці-записи на один і той же кадр? Це означає, що цей кадр буде спільним; і будь-які зміни, внесені одним процесом, будуть видимі для іншого.

    Тепер ви можете побачити, як реалізуються потоки. У розділі під назвою «клон» ми сказали, що функція Linux clone () може ділитися стільки або менше нового процесу зі старим процесом, скільки це потрібно. Якщо процес викликає clone () для створення нового процесу, але запитує, що обидва процеси мають однакову таблицю сторінок, то у вас фактично є потік, оскільки обидва процеси бачать однакову основну фізичну пам'ять.

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

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

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

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

    Ці сторінки повинні бути першими, щоб бути видалені в міру збільшення тиску пам'яті в системі.

    Термін, який ви можете почути під час обговорення ядра, - це кеш сторінок.

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