Московский физико-технический институт
Опубликован: 12.12.2007 | Доступ: свободный | Студентов: 5591 / 1909 | Оценка: 4.34 / 4.14 | Длительность: 13:57:00
ISBN: 978-5-94774-827-7
Лекция 10:

Функционирование менеджера памяти

< Лекция 9 || Лекция 10: 123 || Лекция 11 >

Эксперимент. Наблюдение за ошибками страниц

Количество ошибок страниц, генерируемых процессом, можно наблюдать при помощи счетчика "Ошибок страницы". На рис. приведены графики поведения счетчиков "Ошибок страниц" и "Рабочее множество" для процесса DempPageFaults. (см. программу, описанную выше)

Наблюдение за размером рабочего набора процесса и количеством страничных ошибок

Рис. 10.6. Наблюдение за размером рабочего набора процесса и количеством страничных ошибок

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

При помощи утилиты Pfmon.exe из ресурсов Windows можно не только "увидеть" общее количество страничных нарушений, но и определить виртуальные адреса, обращения к которым эти нарушения спровоцировали. На примере 10.1 приведен фрагмент результатов работы данной утилиты для процесса DemoPageFaults.

…
SOFT: RtlFillMemoryUlong+0x10 : 0x00232000
SOFT: RtlFillMemoryUlong+0x10 : 0x00233000
SOFT: GetConsoleInputWaitHandle+0x11a : GetConsoleInputWaitHandle+0x119
SOFT: FindFirstFileExA+0x285 : FindFirstFileExA+0x285
SOFT: main+0xe4 : 0x00440000
SOFT: main+0xe4 : 0x00441000
SOFT: main+0xe4 : 0x00442000
SOFT: main+0xe4 : 0x00443000
SOFT: main+0xe4 : 0x00444000
SOFT: main+0xe4 : 0x00445000
SOFT: main+0xe4 : 0x00446000
SOFT: main+0xe4 : 0x00447000
SOFT: main+0xe4 : 0x00448000
SOFT: main+0xe4 : 0x00449000
SOFT: main+0xe4 : 0x0044a000
SOFT: main+0xe4 : 0x0044b000
SOFT: main+0xe4 : 0x0044c000
SOFT: main+0xe4 : 0x0044d000
SOFT: main+0xe4 : 0x0044e000
SOFT: main+0xe4 : 0x0044f000
SOFT: main+0xe4 : 0x00450000
SOFT: main+0xe4 : 0x00451000
SOFT: main+0xe4 : 0x00452000
SOFT: main+0xe4 : 0x00453000
SOFT: main+0xe4 : 0x00454000
SOFT: main+0xe4 : 0x00455000
…
Пример 10.3. Часть результатов работы утилиты Pfmon.exe по отношению к процессу DemoPageFaults

Отдельные аспекты функционирования менеджера памяти

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

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

Локализация страниц в памяти

По умолчанию, процессу разрешается блокировать максимум 30 страниц памяти. Если увеличить рабочее множество процесса при помощи функции SetProcessWorkingSetSize, то, согласно документации, максимальное число страниц, которое процесс может блокировать, равно минимальному размеру его рабочего набора за вычетом 8 страниц.

Локализация страниц в памяти осуществляется при помощи Win32 функции VirtualLock, а освобождение страниц - при помощи VirtualUnlock. Учет локализованных страниц ведется в страничной базе PFN.

Прогон программы, демонстрирующей блокировку страниц в памяти

Приведенный листинг является примером такой программы.

#include <windows.h>
#include <stdio.h>

void main(void)
{

PVOID pMem = NULL;
int nPageSize = 4096;
int nPages = 400;
int nPageLock = 100;
long SizeCommit = 0;
int i;
char * Ptr;
int nMinPages = 200, nMaxPages = 500;
long dwMinimumWorkingSetSize = 0, dwMaximumWorkingSetSize = 0;
HANDLE hProcess;

hProcess = GetCurrentProcess();
dwMinimumWorkingSetSize = nMinPages * nPageSize;
dwMaximumWorkingSetSize = nMaxPages * nPageSize;

i = SetProcessWorkingSetSize(hProcess, dwMinimumWorkingSetSize, dwMaximumWorkingSetSize);
if(i==0) printf("SetProcessWorkingSetSize Error\n");

SizeCommit = nPages * nPageSize;

pMem =  VirtualAlloc(0, SizeCommit, MEM_RESERVE| MEM_COMMIT, PAGE_READWRITE);
if(pMem == NULL) printf("VirtualAlloc Error\n");

Ptr = (char *)pMem;
for(i=0; i<nPages; i++) Ptr[i*nPageSize] = '0';

i = VirtualLock(pMem, nPageLock * nPageSize);
if(i==0) printf("VirtualLock Error\n");

for(i=0; i<nPages; i++) Ptr[i*nPageSize] = '0';

VirtualUnlock(pMem, nPageLock * nPageSize);
VirtualFree(pMem, 0, MEM_RELEASE);
}

Копирование при записи

Другой нюанс в работе менеджера памяти, который можно проиллюстрировать на практике, связан с реализацией алгоритма отложенного выделения памяти - копирование при записи (copy-on-write). Это один из примеров алгоритма отложенной оценки (lazy evaluation), которые усложняют систему, но делают её более эффективной.

Рассмотрим ситуацию, когда некоторая приватная область памяти процесса является точной копией уже существующего в системе фрагмента памяти. Например, память дочернего процесса после вызова функции fork() в Unix является копией памяти родительского процесса. Другой пример - совместное использование динамической библиотеки, до тех пор, пока одна из программ не поменяла ее статические данные. В таких случаях разумно не выделять отдельную область памяти для процесса, а отображать в его адресное пространство уже существующую. Собственно выделение можно осуществить тогда, когда процесс приступит к изменению содержимого этой области. Эта техника называется копированием при записи.

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

Прогон программы, иллюстрирующей отложенное выделение памяти

#include <windows.h>
#include <stdio.h>

void main(void)
{
HANDLE hMapFile;
LPVOID lpMapAddress;
HANDLE hFile; 
char * String;
 
hFile = CreateFile("MyFile.txt",GENERIC_READ | GENERIC_WRITE,
		       FILE_SHARE_READ| FILE_SHARE_WRITE, NULL, OPEN_ALWAYS,
                    FILE_ATTRIBUTE_NORMAL,NULL);
 
if (hFile == INVALID_HANDLE_VALUE) printf("Could not open file\n"); 

hMapFile = CreateFileMapping(hFile, NULL, 
                             PAGE_WRITECOPY,  // копирование при записи                                        
                             0,0,"MyFileObject");
                              
if (hMapFile == NULL)  printf("Could not create file-mapping object.\n"); 

 lpMapAddress = MapViewOfFile(hMapFile, 
                              FILE_MAP_COPY, // копирование при записи							    
                              0,0,0);
                              
if (lpMapAddress == NULL) printf("Could not map view of file.\n"); 

 String = (char *)lpMapAddress;
 getchar();
 sprintf(String, "Hello, world");
 printf("%s\n", String);

if (!UnmapViewOfFile(lpMapAddress))  printf("Could not unmap view of file.\n"); 
}

В приведенной программе часть страниц отображаемого файла помечена атрибутом PAGE_WRITECOPY. Запись текстовой строки в данный регион памяти осуществляется после нажатия клавиши "Enter". Рекомендуется осуществить прогон программы, наблюдая за счетчиком "запись копий страниц" при нажатии клавиши "Enter". Любопытно, что содержимое исходного файла при этом не меняется.

Контроль процессом памяти другого процесса

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

Для доступа к памяти процесса нужно получить его описатель. Наиболее естественный способ получения описателя - получение описателя дочернего процесса путем извлечения его из параметра lProcessInformation функции CreateProcess.

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

Написание, компиляция и выполнение программы, осуществляющей доступ к памяти дочернего процесса

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

Заключение

Базовой операцией менеджера памяти является трансляция виртуального адреса в физический с помощью таблицы страниц и ассоциативной (TLB) памяти. В ряде случаев, для реализации разделяемой памяти, интеграции с системой ввода-вывода и др., применяется прототипная таблица страниц, которая является промежуточным звеном между обычной таблицей страниц и физической памятью. Для описания страниц физической памяти поддерживается база данных PFN (page frame number). Локализацию страниц памяти, контроль процессом памяти другого процесса и технику копирования при записи можно отнести к интересным особенностям системы управления памятью ОС Windows.

< Лекция 9 || Лекция 10: 123 || Лекция 11 >
Ирина Оленина
Ирина Оленина
Николай Сергеев
Николай Сергеев

Здравствуйте! Интересует следующий момент. Как осуществляется контроль доступа по тому или иному адресу с точки зрения обработки процессом кода процесса. Насколько я понял, есть два способа: задание через атрибуты сегмента (чтение, запись, исполнение), либо через атрибуты PDE/PTE (чтение, запись). Но как следует из многочисленных источников, эти механизмы в ОС Windows почти не задействованы. Там ключевую роль играет менеджер памяти, задающий регионы, назначающий им атрибуты (PAGE_READWRITE, PAGE_READONLY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_NOACCESS, PAGE_GUARD: их гораздо больше, чем можно было бы задать для сегмента памяти) и контролирующий доступ к этим регионам. Непонятно, на каком этапе может включаться в работу этот менеджер памяти? Поскольку процессор может встретить инструкцию: записать такие данные по такому адресу (даже, если этот адрес относится к региону, выделенному менеджером памяти с атрибутом, например, PAGE_READONLY) и ничего не мешает ему это выполнить. Таким образом, менеджер памяти остается в стороне не участвует в процессе...