Математика : Курсовая работа: Мониторинг виртуальной памяти в ОС Linux
Курсовая работа: Мониторинг виртуальной памяти в ОС Linux
РАСЧЕТНО-ПОЯСНИТЕЛЬНАЯ
ЗАПИСКА
к курсовой работе на
тему:
"Мониторинг виртуальной памяти в ОС Linux"
Введение
Зачастую бывает необходимо отследить за работой
того или иного процесса с памятью, например, чтобы обнаружить утечки памяти,
узнать, в какие моменты и сколько памяти процесс выделяет. Для решения данной
задачи существует ряд средств, а именно:
·
Файловая
система /proc – позволяет прочесть различную информацию о всей системе в целом
и о каждом из процессов, в том числе информацию об использовании процессом
памяти и об отображениях памяти данного процесса. (пример:
# cat /proc/`pgrep
test`/status
Name: test1
…
VmPeak: 1556 kB
VmSize: 1544 kB
VmLck: 0 kB
VmHWM: 308 kB
VmRSS: 308 kB
VmData: 148 kB
VmStk: 88 kB
VmExe: 4 kB
VmLib: 1276 kB
VmPTE: 12 kB
# cat /proc/`pgrep
test`/maps
08048000–08049000 r-xp
00000000 08:01 17432879 /home/twee/work/mstu/coding/memmon/test/test1
08049000–0804a000 rw-p
00000000 08:01 17432879 /home/twee/work/mstu/coding/memmon/test/test1
0804a000–0806b000 rw-p
0804a000 00:00 0 [heap]
b7e4b000‑b7e4c000
rw-p b7e4b000 00:00 0
b7e4c000‑b7f75000
r-xp 00000000 03:05 1604119 /lib/tls/libc‑2.3.6.so
b7f75000‑b7f76000 r–p
00128000 03:05 1604119 /lib/tls/libc‑2.3.6.so
b7f76000‑b7f79000
rw-p 00129000 03:05 1604119 /lib/tls/libc‑2.3.6.so
b7f79000‑b7f7c000
rw-p b7f79000 00:00 0
b7f9d000‑b7fb3000
r-xp 00000000 03:05 752968 /lib/ld‑2.3.6.so
b7fb3000‑b7fb5000
rw-p 00015000 03:05 752968 /lib/ld‑2.3.6.so
bfc2a000‑bfc40000
rw-p bfc2a000 00:00 0 [stack]
ffffe000‑fffff000
r-xp 00000000 00:00 0 [vdso]
). На приведенной распечатке видно, сколько
памяти использует процесс test и под какие именно нужды, а так же его
карту памяти. Однако таким образом нельзя отследить динамику работы процесса с
памятью.
·
strace – утилита, позволяющая
трассировать все системные вызовы, выполняемые данным процессом (в частности,
выделение памяти вызовами brk/mmap). Она использует стандартный
отладочный механизм ядра под названием ptrace – подключается к
исследуемому процессу как отладчик (вызовов ptrace(), указывая при этом
флаг PTRACE_SYSCALL, что заставляет систему уведомлять трассирующий
процесс о всех системных вызовах трассируемого). Пример его работы:
execve (»./test3», [«test3»], [/* 61 vars */]) =
0
…
fsync(0) = -1 EINVAL (Invalid argument)
mmap2 (NULL, 2101248,
PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7bf4000
fsync(1) = -1 EINVAL
(Invalid argument)
fsync(2) = -1 EINVAL
(Invalid argument)
munmap (0xb7bf4000, 2101248) = 0
exit_group(0)
На приведенной трассировке видно, как процесс
выделяет и освобождает 2101248 байт памяти. К сожалению, это средство не
позволяет следить за всеми процессами в системе в целом, а так же за выделениями
физических страниц процессу.
Таким образом, возникает необходимость в
средстве, позволяющем отслеживать не только выделения виртуальной памяти
процессу, но и выделения отдельных страниц физической памяти в результате
страничных сбоев.
1.
Аналитический раздел
1.1
Постановка задачи
Разработать драйвер под Linux, отслеживающий
выделение и освобождение процессами виртуальной памяти и выделение физических
страниц при страничных отказах.
Драйвер должен поддерживать динамическую загрузку
и выгрузку без перезапуска системы и задание списка процессов, за которыми
необходимо выполнять мониторинг.
Взаимодействие с пользовательской программой
осуществляется посредством файлов, создаваемых в файловой системе /proc.
Ядро отвечает за создание и уничтожение процессов
и за их связь с внешним миром (ввод и вывод). Взаимодействие процессов друг с
другом (посредством сигналов, программных каналов или других средств
межпроцессного взаимодействия) является основой общей системной
функциональности, и тоже осуществляется при помощи ядра. Планировщик,
распределяющий время центрального процессора между процессами, является частью
подсистемы управления процессами. В общих словах, подсистема управления
процессами реализует абстракцию множества процессов, работающих одновременно на
одном или нескольких процессорах.
1.1.1 Управление памятью
Память компьютера – один из главных ресурсов, и
производительность системы критически зависит от политики распределения памяти.
Ядро создает виртуальное адресное пространство для каждого процесса, используя
при этом ограниченное количество физической памяти и, при необходимости,
вторичную память, такую, как жесткий диск. По мере необходимости страницы могут
быть выгружены в файл подкачки, либо файл, из которого они были отображены в
память (в случае, если они не были модифицированы с момента загрузки из файла,
они просто удаляются из памяти). По умолчанию ядро не позволяет выделить одному
процессу больше памяти, чем суммарный объем доступной оперативной и swap‑памяти.
Однако есть такая возможность, как overcommit («перевыделение»), которая
позволяет выделить гораздо больше памяти, при условии, что реально
использоватьcя будет лишь небольшая ее часть (допустим, при работе с
разреженным массивом). Overcommit включается командой
# echo 1 > /proc/sys/vm/overcommit_memory
а отключается
# echo 0 >
/proc/sys/vm/overcommit_memory
Цифра 1 означает выбранный режим управления
перевыделением (0 означает его отсутствие, 1 – допустимо перевыделение
неограниченных объемов памяти, 2 – некоторый эвристический алгоритм определения
максимально допустимого объема перевыделения).
1.1.2 Файловая система
Система Linux основана на концепции файловой системы.
Практически любой объект системы может быть рассмотрен как файл. Ядро строит
единую иерархическую файловую систему (единое дерево директорий) на основе не
обладающего иерархической структурой оборудования. В результате абстракция
файла активно используется всей системой.
1.1.3 Подсистема ввода-вывода
Практически любая операция в системе есть, по
сути, операция с устройством. За исключением процессора, памяти и очень
небольшого числа других элементов, порядок выполнения работы с устройством, а
следовательно и исполняемый код, выполняющий эту работу, зависит главным
образом от конкретного устройства. Такой код называется драйвером устройства.
Ядро должно включать в себя драйверы для всех периферийных устройств, входящих
в систему, от жесткого диска до клавиатуры.
1.1.4 Сетевая подсистема
Ядро должно управлять работой с сетью, поскольку
большинство сетевых операций не зависит от процесса. Приходящие сетевые пакеты
являются асинхронными событиями, т.е. во время работы одного процесса может
прийти пакет, адресованный другому процессу. Пакеты должны быть приняты,
распознаны и распределены до того, как о них узнает процесс. Система отвечает
за передачу данных через программные и сетевые интерфейсы, а так же управлять
выполнением программ в соответствии с работой сети. К тому же, все задачи
маршрутизации и выделения сетевых адресов выполняет ядро.
1.1.5 Системные вызовы
Системные вызовы, такие как open(), fork(),
read(), etc являются связующим интерфейсом между ядром и
пользовательскими приложениями. В Linux 2.6 существует около 330 различных
вызовов (многие из них избыточны или сохранены по причинами совместимости). Их
вызов происходит через прерывание 0x80 или инструкцию sysenter (на современных
процессорах). При этом в регистр EAX помещается номер системного вызова,
а в остальные 6 регистров (кроме ESP) – аргументы (т.е. любой системный
вызов может принимать до шести 32‑битных аргументов) в порядке EBX,
ECX, EDX, ESI, EDI, EBP. Точка входа всех системных вызовов расположена в
файле arch/i386/kernel/entry.S, который вызывает обработчик конкретного
вызова по таблице вызовов sys_call_table, передавая ей регистры через
стек.
1.1.6 Загружаемые модули
Одна из важных особенностей ядра Linux – это способность
расширять собственную функциональность непосредственно в период выполнения.
Каждый фрагмент исполняемого кода, который может
быть добавлен в ядро во время его работы, называется модулем ядра. Каждый
модуль создается из объектного кода, не связанного в полноценный исполняемый
файл. Модуль может быть загружен в ядро с помощью программы insmod (вызывающей функции create_module() / init_module()), и выгружен с помощью rmmod (вызывающего delete_module()). В данной работе
реализует именно такой динамически загружаемый модуль.
1.1.7 Типы устройств
В Linux различают три основных типа устройств. Каждый
драйвер обычно соответствует одному из этих типов. Выделяют:
·
Символьные
драйверы
·
Блочные
драйверы
·
Сетевые
драйверы
Символьное устройство может рассматриваться как
поток байт (так же как и файл); символьный драйвер должен реализовывать такое
поведение. Такой драйвер имеет, как правило, функции открытия, закрытия, чтения
и записи. Текстовая консоль и последовательный порт – примеры символьных
устройств. Они могут легко быть представлены абстракцией потоков. Работа с
символьными устройствами осуществляется через специальные файлы устройств,
находящиеся в директории /dev. Единственное значимое отличие обычного файла от
такого устройства – это произвольный доступ, тогда как к большинству символьных
устройств можно обращаться лишь последовательно.
Как и к символьным, доступ к блочным устройствам
можно получить через файлы в директории /dev. Блочное устройство
это устройство (например, диск), способное содержать в себе файловую систему. В
системе Unix блочное устройство может лишь передавать один или более целых
блоков данных, обычно по 512 байт. Интерфейс взаимодействия блочных драйверов с
ядром значительно отличается от интерфейса символьных драйверов.
Любая сетевая транзакция выполняется через
интерфейс сокетов. Сетевой интерфейс отвечает за передачу и прием пакетов под
управлением сетевой подсистемы ядра вне зависимости от того, к каким именно
транзакциям они относятся. Многие сетевые соединения (особенно использующие
протокол TCP) ориентированы на потоки данных. Но сетевые устройства обычно
работают с пакетами, а не с потоками. Таким образом, сетевые устройства
содержат в себе черты как символьных, так и блочных.
2.
Конструкторский раздел
2.1
Модульная структура драйвера
Драйвер
memmon состоит из следующих модулей:
mmon.c – основной модуль, отвечающий за инициализацию и
выгрузку драйвера
mm-fault.c – обработчик страничных ошибок
syscalls.c – высокоуровневая часть перехвата
системных вызовов
syscalls-entry.S – низкоуровневая часть
перехвата системных вызовов
watch-pids.c – список процессов, за которыми
осуществляется мониторинг, добавление и удаление из него
events.c – кольцевой буфер событий
2.2
Инициализация и выгрузка драйвера
Инициализацию драйвера выполняет функция int
__init init(void). Она вызывается при загрузке драйвера в контексте
процесса, вызвашего init_module() (системный вызов загрузки драйвера) и
выполняет следующие действия:
1.
Инициализирует
битовую карту отслеживаемых процессов и кольцевой буфер событий
2.
Устанавливает
обработчики системных вызовов и страничной ошибки
3.
Создает
директорию /proc/memmon и файлы в ней
Создание файлов происходит в последнюю очередь для
того, чтобы пользовательские приложения не могли обратиться к драйверу до
завершения инициализации.
Выгрузку выполняет функция void __exit
exit(void), вызываемая в контексте процесса, сделавшего delete_module().
Она выполняет действия, обратные к init():
1.
Удаляет
директорию /proc/memmon
2.
Снимает
перехват системных вызовов и страничного отказа
3.
Освобождает
память
2.3
Взаимодействие с пользовательскими приложениями
Для взаимодействия с пользовательскими
приложениями драйвер использует файловую систему procfs – псевдо-файловую
систему, предоставляющую различную информацию о системе. Любой драйвер может
добавлять в ее иерархию свои файлы и папки для передачи пользовательским
программам различной информации. Ядро предоставляет ряд функций для работы с procfs,
из который данный драйвер использует следующие:
proc_mkdir() – создает папку в /proc
create_proc_entry() – создает файл в указанной
папке /proc или самой /proc
remove_proc_entry() – удаляет папку или файл в /proc
На уровне ядра Linux любой открытый файл
представлен структурой file, хранящей указатель f_fops на
структуру file_operations, содержащую адреса обработчиков различных
запросов к файлу. Допустим, когда приложение открывает файл (делая системный
вызов open()), он вызывает обобщенный уровень файловых систем VFS
(функцию vfs_read()), которая в свою очередь вызывает обработчик f_ops->open.
Для обычных файловых систем обработчики запросов к файлу находятся в драйвере
файловой системы, которой принадлежит данный файл. Однако /proc не
представляет из себя какой-либо реальной ФС на реальном хранилище данных, и
каждый драйвер, добавляющий туда файлы, должен для них предоставлять свои
обработчики (точки входа), которые и будут вызываться при работе с этими
файлами.
Файлы, создаваемые в /proc, представляются
структурой proc_entry, содержащую поле proc_fops, куда и заносится указатель на
структуру file_operations для данного файла.
Данный драйвер создает в папке /proc/memmon 2
файла – watch-pids – для добавления / удаления процессов в список
отслеживаемых и events – файл, содержащий собственно лог событий.
2.4
Перехват системных вызовов
Одно из основных действий, выполняемых драйвером
перехват системных вызовов.
Это довольно небезопасный прием, так как если 2
драйвера перехватят один и тот же вызов, и будут выгружены не в том порядке, в
каком загрузились, последний восстановит неверный адрес в таблице вызовов,
вследствие чего произойдет сбой при следующей попытке сделать данный вызов. В
связи с этим, начиная с версии 2.5, ядро более не экспортирует таблицу
системных вызовов. Тем не менее, эта проблема устраняется небольшим
исправлением ядра (patch), который добавляет в произвольный файл ядра следующие
строки, экспортирующие из ядра данную таблицу.
extern void
*sys_call_table[];
EXPORT_SYMBOL_GPL (sys_call_table);
Для перехвата системных вызовов имеются 3 таблицы
указателей – оригинальных (системных) обработчиков, наших пре-обработчиков
(вызываемых ДО оригинального, и принимающих аргументы) и пост-обработчиков
(вызываемых ПОСЛЕ и принимающих возвращаемое значение):
void *old_sys_call [NR_syscalls];
void *sys_call_trap [NR_syscalls];
void *sys_call_exit [NR_syscalls];
Кроме того, есть общая таблица структур, каждый
элемент которой описывает один из перехватываемых системных вызовов:
struct syscall_handler
{
/* Syscall nr */
int nr;
/* Pre-call &
post-call handler */
void *hand1, *hand2;
};
Функция capture_syscalls(), вызываемая при инициализации драйвера, копирует эти адреса в предыдущие 2 таблицы и записывает в sys_call_table по нужным номерам адрес универсального перехватчика – syscalls_entry,
находящегося в файле syscalls-entry.
Необходимость в ассемблерном коде обусловлена
механизмом обработки системных вызовов в Linux. На рис. 3 показан стек на
момент вызова обработчика системного вызова (замененного или стандартного).
Проблема заключается в том, что некоторые стандартные обработчики требуют,
чтобы стек имел именно такой вид, и если вызывать их из нового обработчика, они
правильно работать не будут. В связи с этим syscalls_entry сначала вызывает
пре-обработчик системного вызова, затем заменяет в стеке адрес возврата на
адрес следующей инструкции и делает переход на стандартный обработчик, который
получает кадр стека в изначальном виде. Затем, при возврате, мы попадаем на
следующую инструкцию, которая вызывает пост-обработчик и делает перход на
изначальный адрес возврата, на код в arch/i386/kernel/entry.S (точки
входа всех системных вызовов в Linux). Этот адрес сохраняется внизу стека ядра,
там же где хранится указатель на текущую задачу и некоторая другая служебная
информация ядра. Данные действия продемонстрированы на рис. 3.3–3.5.
Данный драйвер перехватывает следующие системные
вызовы:
m[un] map() – выделение / освобождение региона
памяти
mremap() – перемещение региона памяти
brk() – расширение / сужение сегмента данных
программы
m[un] lock[all]() – блокировка набора страниц
в рабочем множестве процесса
fsync() – используется в качестве маркера в журнале событий
Для каждого из вызовов в журнал печатается имя
вызова, PID вызвавшего процесса и список (с расшифровкой, там, где это имеет
смысл) аргументов.
2.5
Кольцевой буфер событий
Для хранения журнала событий, таких как выделение
блоков виртуальной памяти и страниц, использует кольцевой буфер, защищенный
спин-блокировкой. Размер данного буфера может задаваться при загрузке драйвера
в качестве его параметра, значение по умолчанию – 32 кб, минимальное – 8 кб.
Память для буфера выделяется функцией kzalloc() – аналогом фукнций malloc/calloc()
из стандартной библиотеки С. Передаваемый ей параметр GFP_KERNEL
означает, что память выделяется для ядра (т.е. не может быть позже выгружена с
диска), но не в атомарном контексте (т.е. текущий процесс может быть отложен до
освобождения необходимой памяти).
Каждая запись в буфере представляет из себя
следующую структуру:
enum memmon_event_type – тип события
{
NOTUSED = 0
MMAP2,
MUNMAP,
MREMAP,
MLOCK,
MUNLOCK,
MLOCKALL,
MUNLOCKALL,
BRK,
FSYNC,
ANON_PF, – страничная ошибка на анонимной
странице
SWAP_PF, – на странице из файла подкачки
FILE_PF, – из разделяемого файла
SYSCALLRET – возврат из системного вызова
};
struct memmon_event
{
enum memmon_event_type
type; – тип события
pid_t pid; – PID вызвавшего процесса
union – специфичны для события данные
{
struct
{
void __user *start;
size_t len;
} munmap;
struct
{
void __user *start;
size_t len;
unsigned long prot,
flags;
unsigned long fd, off;
} mmap2;
……
};
}
С буфером событий связаны следующие переменные:
static struct
memmon_event *events; – собственно буфер
static int ev_start; – индекс самой старой записи
в буфере
static int ev_end; – индекс последней записи
static int ev_ovf = 0; – было ли уже переполнение
буфера
DECLARE_WAIT_QUEUE_HEAD (ev_waitq); – очередь
ожидания (для блокирующего чтения)
spinlock_t ev_lock = SPIN_LOCK_UNLOCKED; – спин-блокировка
для защиты от гонок при обращении к буферу
Пользовательские приложения запрашивают
содержимое буфера событий, читая файл /proc/memmon/events. Если при
открытии файла не был установлен флаг O_NONBLOCK, операция чтения по
нему блокирующая – т.е., если новых данных в буфере нет, read()
переводит процесс в состояние ожидания (interruptible | 
