Добавлен: 29.10.2018
Просмотров: 47999
Скачиваний: 190
1016
Глава 11. Изучение конкретных примеров: Windows 8
Измененная
Неизмененная
Неизмененная
Неизмененная
Измененная
Измененная
Рис. 11.19. Некоторые из основных полей базы данных страничных блоков
для действительной страницы
Страницы перемещаются из рабочих наборов в списки диспетчером рабочих наборов
и прочими системными потоками. Давайте изучим эти перемещения. Когда диспетчер
рабочих потоков удаляет страницу из рабочего набора, эта страница попадает в ниж-
нюю часть списка резервных или модифицированных страниц в зависимости от со-
стояния ее измененности. Это переход показан на рис. 11.20 как (1).
Рис. 11.20. Различные списки страниц и переходы между ними
11.5. Управление памятью
1017
Страницы обоих списков — это действительные страницы, так что если происходит
страничная ошибка и нужна одна из этих страниц, то она удаляется из списка и до-
ставляется в рабочий набор без выполнения дискового ввода-вывода (2). Когда про-
цесс завершается, те его страницы, которые не используются совместно, не могут быть
ему доставлены, так что действительные страницы из его таблицы страниц и все его
страницы из модифицированного и резервного списков попадают в список свободных
страниц (3). Освобождается также используемое процессом место в файле подкачки.
Остальные переходы вызываются другими системными потоками. Каждые 4 с запуска-
ется поток диспетчера установки баланса, который ищет такие процессы, все потоки
которых находятся в бездействии в течение определенного количества секунд. Если он
находит такие процессы, то их стеки ядра открепляются от физической памяти и их стра-
ницы переносятся в списки резервных или модифицированных (также показано как (1)).
Два других системных потока (записи отображенных страниц — mapped page writer
и записи модифицированных страниц — modified page writer) периодически просыпа-
ются и смотрят, достаточно ли неизмененных страниц. Если их мало, то они берут стра-
ницы из верхней части списка измененных страниц, записывают их обратно на диск,
а затем переносят в список резервных страниц (4). В первом списке учитываются запи-
си в отображенные файлы, а во втором — записи в файл подкачки. В результате этих
записей измененные страницы преобразуются в резервные (неизмененные) страницы.
Причина наличия двух потоков состоит в том, что отображенному файлу в результате
записи может понадобиться увеличить размер, а для его увеличения требуется доступ
к дисковым структурам данных (для выделения свободного блока на диске). Если в па-
мяти недостаточно места, чтобы разместить их (при необходимости выполнить запись
страницы), то может получиться взаимоблокировка. Второй поток может решить эту
проблему, записав страницы в файл подкачки.
Остальные переходы на рис. 11.20 выполняются следующим образом. Когда процесс
отменяет отображение страницы, эта страница более не связана с данным процессом
и может переходить в список свободных (5), если только она не является совместно
используемой. Когда страничная ошибка требует, чтобы страничный блок содержал
ту страницу, которая будет читаться, страничный блок берется из списка свободных
страниц (6), если это возможно. Не имеет значения то, что страница может содержать
какую-либо конфиденциальную информацию, поскольку она будет полностью пере-
записана.
При увеличении стека ситуация иная. В этом случае нужен пустой страничный блок,
и правила безопасности требуют, чтобы страница содержала одни нули. По этой при чине
запускается (с низким приоритетом) другой системный поток (ZeroPage), который за-
тирает страницы из списка свободных и помещает их в список обнуленных (7). Когда
процессор находится в бездействии и есть свободные страницы, они также могут об-
нуляться, поскольку обнуленная страница потенциально более полезна, чем свободная
(а обнуление страницы при бездействующем процессоре практически ничего не стоит).
Существование этих списков приводит к необходимости принимать некоторые тонкие
стратегические решения. Например, предположим, что страницу нужно доставить
с диска, а список свободных страниц пуст. Системе нужно сделать выбор: взять неиз-
мененную страницу из резервного списка (которая в противном случае может быть
затем возвращена по страничной ошибке) или пустую страницу из списка обнуленных
страниц (сделав напрасной проделанную по ее обнулению работу). Что лучше?
1018
Глава 11. Изучение конкретных примеров: Windows 8
Диспетчер памяти должен решить, насколько агрессивно системные потоки должны
перемещать страницы из списка модифицированных в список резервных. Иметь неиз-
мененные страницы лучше, чем иметь измененные, поскольку их можно использовать
немедленно, но агрессивная стратегия очистки приводит к увеличению дискового вво-
да-вывода и есть некоторая вероятность того, что только что очищенная страница мо-
жет быть доставлена по страничной ошибке в рабочий набор и опять изменена. В общем
случае Windows разрешает все эти противоречия при помощи алгоритмов, эвристик,
допущений, исторических прецедентов, эмпирических правил, а также управляемых
администраторами значений параметров.
В современной Windows введен дополнительный уровень абстракции в нижней части
диспетчера памяти, который называется диспетчером хранилища (store manager). На
этом уровне принимаются решения о том, как оптимизировать операции ввода-вывода
с доступными резервными хранилищами. Постоянные системы хранения в дополнение
к вращающимся дискам включают вспомогательную флеш-память и твердотельные
диски (SSD). Диспетчер хранилища оптимальным образом решает, где и как страницы
физической памяти получают резервную копию в постоянных хранилищах в системе.
Он также реализует такие оптимизационные технологии, как совместное использо-
вание одинаковых физических страниц с помощью копирования при записи, а также
сжатие страниц, находящихся в списке готовых к использованию для эффективного
повышения объема доступной оперативной памяти.
Еще одним изменением в диспетчеризации памяти в современной Windows является
введение файла подкачки. Исторически управление памятью в Windows основыва-
лось, как описано ранее, на рабочих наборах. С возрастанием дефицита памяти дис-
петчер памяти принуждает рабочий набор к сокращению тех следов, которые каждый
процесс имеет в памяти. Модель современных приложений вводит возможности для
новых эффективных решений. Поскольку процессу, содержащему ту часть современ-
ного приложения, которая относится к переднему плану, с переключением пользова-
теля на другое приложение ресурсы процессора больше не выделяются, его страницам
оставаться в памяти необязательно. По мере возрастания дефицита памяти в системе
страницы в процессе могут быть удалены в ходе обычного управления рабочим на-
бором. Но диспетчер времени выполнения процесса знает, сколько прошло времени
с момента переключения пользователя на процесс переднего плана приложения. Когда
требуется еще больше памяти, выбирается процесс, который не выполнялся, и проис-
ходит вызов диспетчера памяти для эффективного сброса всех страниц за небольшое
количество операций ввода-вывода. Страницы будут записаны в файл подкачки путем
объединения их в один или несколько больших участков памяти. Это означает, что
весь процесс также может быть восстановлен в памяти с использованием небольшого
количества операций ввода-вывода.
Управление памятью является очень сложным компонентом исполнительного уровня
(с множеством структур данных, алгоритмов и эвристик). Оно в значительной степени
самонастраиваемое, но есть также масса параметров, которыми администраторы могут
настраивать производительность системы. Некоторые из этих параметров и соответ-
ствующие им счетчики можно просмотреть при помощи инструментов из различных
инструментальных наборов (которые упоминались ранее). Вероятно, самая важная
вещь, которую необходимо помнить, — это то, что управление памятью в реальных
системах не только один простой алгоритм для файла подкачки.
11.6. Кэширование в Windows
1019
11.6. Кэширование в Windows
Кэш в Windows улучшает производительность файловых систем (сохраняя недавно
и часто используемые области файлов в памяти). Вместо кэширования физических
адресуемых блоков с диска диспетчер кэширования управляет виртуально адресуемы-
ми блоками, то есть областями файлов. Такой подход хорошо согласуется со структурой
файловой системы NTFS (как мы увидим в разделе 11.8). NTFS хранит все свои данные
как файлы (в том числе метаданные файловой системы).
Кэшированные области файлов называются представлениями (views), поскольку
они представляют области виртуальных адресов ядра, которые отображены на файлы
файловой системы. Таким образом, реальное управление физической памятью кэша
обеспечивается диспетчером памяти. Роль диспетчера кэширования состоит в управ-
лении использованием виртуальных адресов ядра для представлений, организации
(совместно с диспетчером памяти) закреплении страниц в физической памяти и предо-
ставлении интерфейсов для файловых систем.
Средства диспетчера кэширования в Windows совместно используются всеми файло-
выми системами. Поскольку кэш адресуется виртуально (в соответствии с отдельными
файлами), то диспетчер кэширования может выполнять упреждающее чтение для
каждого файла отдельно. Запросы на доступ к кэшированным данным приходят из всех
файловых систем. Виртуальное кэширование удобно, поскольку файловые системы
не должны предварительно преобразовывать смещение в файле в номер физического
блока (перед запросом кэшированной страницы файла). Это преобразование проис-
ходит позднее, когда диспетчер памяти вызывает файловую систему для обращения
к странице на диске.
Помимо управления используемыми для кэширования виртуальными адресами ядра
и ресурсами физической памяти диспетчер кэширования также должен координи-
ровать свои действия с файловыми системами (по таким вопросам, как непротиво-
речивость представлений, сброс на диск, а также правильное обслуживание отметок
конца файла — в частности, при расширении файлов). Одним из наиболее трудных
аспектов файла, которыми приходится управлять файловой системе, диспетчеру
кэширования и диспетчеру памяти, является смещение последнего байта файла, на-
зываемое ValidDataLength. Если программа пишет за концом файла, то пропущенные
блоки должны быть заполнены нулями, и по соображениям безопасности очень важно,
чтобы записанная (в метаданных файла) длина ValidDataLength не давала доступа к не-
инициализированным блокам. Поэтому до обновления метаданных (новым значением
длины) на диск нужно записать нулевые блоки. Понятно, что если система дает сбой, то
некоторые из блоков файла могут оказаться не обновленными из содержимого памяти,
однако совершенно недопустимо, чтобы некоторые блоки содержали такие данные,
которые раньше принадлежали другим файлам.
Теперь давайте изучим работу диспетчера кэширования. Когда делается ссылка на
файл, то диспетчер кэширования выполняет отображение блока (размером 256 Кбайт)
виртуального адресного пространства ядра на файл. Если файл больше, чем 256 Кбайт,
то за один прием отображается только часть файла. Если у диспетчера кэширования
заканчиваются такие блоки адресов, то перед отображением нового файла он должен
отменить отображение старого файла. После отображения файла диспетчер кэширо-
вания может выполнять запросы на его блоки (копируя из виртуального адресного
пространства ядра в буфер пользовательского режима). Если копируемый блок от-
1020
Глава 11. Изучение конкретных примеров: Windows 8
сутствует в физической памяти, то происходит страничная ошибка и диспетчер памяти
обрабатывает ее обычным путем. Диспетчер кэширования даже не знает, был блок
в памяти или нет. Копирование всегда выполняется успешно.
Диспетчер кэширования работает также с теми страницами, которые отображены в вир-
туальную память и доступ к которым производится при помощи указателей (а не за
счет копирования между буферами режима ядра и пользовательского режима). Когда
поток обращается к отображенному на файл виртуальному адресу и происходит стра-
ничная ошибка, диспетчер памяти во многих случаях может обработать доступ как мяг-
кую ошибку. Ему не нужно обращаться к диску, поскольку он видит, что страница уже
находится в физической памяти (так как она отображена диспетчером кэширования).
11.7. Ввод-вывод в Windows
Цель диспетчера ввода-вывода Windows — обеспечить обширную и гибкую основу для
эффективной обработки очень широкого разнообразия устройств и служб ввода-вы-
вода, поддержки автоматического распознавания устройств и инсталляции драйверов
(Plug-and-Play), а также для управления электропитанием устройств и процессора —
и все это с использованием в основном асинхронной структуры, которая позволяет вы-
полнять вычисления одновременно с передачей данных при вводе-выводе. Существуют
сотни тысяч устройств, которые работают с Windows. Для большого количества часто
встречающихся устройств даже не нужно инсталлировать драйвер, поскольку в составе
операционной системы уже есть такой драйвер. Даже с учетом этого (и если считать все
версии) существует почти миллион различных двоичных драйверов, которые работают
под управлением Windows. В следующих разделах мы изучим некоторые из проблем
ввода-вывода.
11.7.1. Фундаментальные концепции
Диспетчер ввода-вывода находится в чрезвычайно близких отношениях с диспетчером
Plug-and-Play. Основная идея Plug-and-Play состоит в том, что существует перечис-
лимая шина. Многие шины (в том числе PC Card, PCI, PCIe, AGP, USB, IEEE-1394,
E-IDE и SATA) были спроектированы таким образом, чтобы диспетчер Plug-and-
Play мог послать запрос на каждый разъем шины и попросить установленное в нем
устройство идентифицироваться. Обнаружив, что именно там установлено, диспетчер
Plug-and-Play назначает аппаратные ресурсы (такие, как уровни прерываний), находит
соответствующие драйверы и загружает их в память. При загрузке каждого драйвера
для него создается объект драйвера (driver object). Затем для каждого устройства
назначается как минимум один объект устройства. Для некоторых шин (таких, как
SCSI) перечисление происходит только в момент загрузки, но для других шин (таких,
как USB) оно может произойти в любой момент, что требует тесного взаимодействия
между диспетчером Plug-and-Play, драйверами шины (которые фактически и выпол-
няют перечисление) и диспетчером ввода-вывода.
В операционной системе Windows все файловые системы, антивирусные фильтры
и даже службы ядра (которым не соответствуют никакие аппаратные средства) реали-
зованы при помощи драйверов ввода-вывода. В системной конфигурации должно быть
указание на необходимость загрузки хотя бы некоторых из этих драйверов, поскольку
не существует устройства-счетчика на шине. Другие (подобно файловым системам)