Переключение контекста: если новый процесс имеет виртуальную память, сопоставленную с тем же физическим адресом, что и предыдущий, как реализуется защита памяти? - PullRequest
0 голосов
/ 26 января 2020

Я знаю, что кэш не сбрасывается при переключении контекста. Таким образом, если новый процесс потребовал страницу, которая отображается на тот же физический адрес, что и предыдущий процесс (и предыдущий процесс теперь перенесен на диск), содержимое предыдущего процесса все равно будет кэшировано. Разве они не будут доступны новому процессу, когда он попытается получить доступ к своей части памяти из физически отображенного кэша?

1 Ответ

1 голос
/ 26 января 2020

, если у нового процесса виртуальная память сопоставлена ​​с тем же физическим адресом, что и предыдущий.

Для большинства современных операционных систем ответ на ваш вопрос Paging .

Допустим, у вас есть ОС с 4 ГБ адресуемой памяти, но физическая память, установленная в системе, составляет всего 2 ГБ. Далее предположим, что активен один процесс с требованием к 1,5 ГБ памяти, поэтому он выглядит следующим образом.

enter image description here

, поскольку физической памяти достаточно, полное виртуальное адресное пространство этого процесса сопоставлено с физической памятью.

Теперь предположим, что в систему входит новый процесс с требованием 1,5 ГБ памяти. Поскольку для обоих процессов недостаточно физической памяти, адресное пространство первого процесса может быть сопоставлено с диском (выгружено), учитывая, что второму процессу активно требуется все 1,5 ГБ его пространства. Итак, теперь ситуация выглядит следующим образом.

enter image description here

Обратите внимание, что с точки зрения первого процесса все как прежде, так как как только он становится активным и использует свое виртуальное пространство, ОС вернется в свое пространство памяти, сохраненное на диске, в физическую память.

Я знаю, что кэш не очищен при переключении контекста. Таким образом, если новый процесс запросил страницу, отображающуюся на тот же физический адрес, что и предыдущий процесс (а предыдущий процесс теперь перенесен на диск), содержимое предыдущего процесса все равно будет кэшировано для защиты памяти.

Ваша предпосылка не совсем верна, где вы читали, что кэш не будет очищен?

Вопрос об отмене кэширования при переключении контекста: зависит от факторов, некоторые из которых не находятся под контролем ОС.

Некоторые реализации ОС делают flu sh кэши (см. Ниже) и те, которые не делают этого, требуют специальной поддержки со стороны оборудования. В любом случае любая ОС, достойная своей соли, будет следить за тем, чтобы недопустимые данные не передавались никаким процессам.

Ниже приводится соответствующий текст из некоторых очень хороших книг по ОС.

Из Понимание Linux Ядро

Таблица 2-11. Зависимые от архитектуры методы недействительности TLB

Имя метода - flush_tlb
Описание - Сбрасывает все записи TLB неглобальных страниц, принадлежащих текущему process Обычно используется, когда - Выполнение переключения процесса

Если CPU переключается на другой процесс, который использует тот же набор таблиц страниц, что и заменяемый поток ядра , ядро ​​вызывает _ _flush_tlb () для аннулирования всех неглобальных записей TLB CPU.

From Современные операционные системы

Наличие кэширования и MMU может существенно повлиять на производительность. В многопрограммной системе при переключении с одной программы на другую, иногда называемую переключением контекста, может потребоваться вывести sh все измененные блоки из кэша и изменить регистры отображения в MMU.

и из операционной системы - три простых компонента

Один из подходов заключается в простом гриппе sh TLB на переключение контекста, таким образом очищая его перед запуском следующего процесса. В программной системе это может быть выполнено с помощью явной (и привилегированной) аппаратной инструкции; с TLB с аппаратным управлением flu sh может быть задействован при изменении базового регистра таблицы страниц (обратите внимание, что операционная система должна изменить PTBR для переключения контекста в любом случае). В любом случае операция сброса просто устанавливает все допустимые биты в 0, по существу очищая содержимое TLB. Сбрасывая TLB при каждом переключении контекста, мы теперь есть работающее решение, поскольку процесс никогда не будет случайно сталкиваться с неправильными переводами в TLB.

С другой стороны, чтобы уменьшить эти издержки, некоторые системы добавляют поддержку аппаратного обеспечения для обеспечения совместного использования TLB через контекстные переключатели . В частности, некоторые аппаратные системы предоставляют поле идентификатора адресного пространства (ASID) в TLB. Вы можете рассматривать ASID как идентификатор процесса (PID), но обычно он имеет меньше битов (например, 8 бит для ASID против 32 бит для PID). Если мы возьмем наш пример TLB сверху и добавим ASID, то ясно, что процессы могут легко разделить TLB: только поле ASID необходимо для различения в противном случае идентичных переводов.

...