Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Удалить его:

$ echo -3000 > /proc/memmon/watch-pids

Добавить процесс с именем test:

$ echo `pgrep test` > /proc/memmon/watch-pids

Удалить все процессы:

$ echo 0 > /proc/memmon/watch-pids

Просмотреть буфер событий:

$ cat /proc/memmon/events

Выгрузка драйвера делается командой

# rmmod procmon.ko

(возможно, только если файлы драйвера никем не открыты)

3. Экспериментальный раздел

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

1) Запрашиваем небольшое количество (3–4) страниц памяти, обращаемся ко всей памяти в этом диапазоне, затем освобождаем ее.

Журнал событий:

29305: anon page @b7ee1fa0 (R)

29305: fsync(0)

29305: anon page @b7f22d4e (R) – страничные отказы в сегменте кода libc.so

29305: anon page @b7ee2000 (R)

29305: anon page @b7e85180 (R)

29305: anon page @b7e86330 (R)

29305: anon page @b7f1f680 (R)

29305: anon page @b7ef6470 (R)

29305: anon page @b7e83140 (R)

29305: anon page @b7e82370 (R)

29305: anon page @b7e87de0 (R)

29305: brk(00000000)

29305: brk -> 134520832 (0804a000)

29305: brk(0806e000)

29305: brk -> 134668288 (0806e000) – malloc выделил 144 кб

29305: anon page @0804a004 (W) – здесь malloc заносит метки в начало и конец выделенного региона

29305: anon page @0804d00c (W)

29305: fsync(1)

29305: anon page @0804b000 (R) – сбои при обращении к страницам из цикла

29305: anon page @0804c000 (R)

29305: fsync(2)

29305: brk(0806b000) – free возвращает часть памяти

29305: brk -> 134656000 (0806b000)

29305: fsync(0) – `дальнейшие циклы уже не выделяют памяти

29305: fsync(1)

29305: fsync(2)

В приведенном примере видно, что при выделении 12К памяти malloc() выделяет изначально гораздо бОльший объем (144К), однако реально эти страницы из физической памяти не выделяеются, и при обращениях к ним происходят страничные отказы. В первую и последнюю страницу выделенной секции malloc заносит свои метки (сбой происходит на операции записи).

2) Выделяем подряд блоки по 4 страницы (не освобождая), обращаясь ко всем страницам:

21049: brk(00000000)

21049: brk -> (0804a000)

21049: brk(0806e000)

21049: brk -> (0806e000) – выделение первого блока, malloc выделяет 144 кб

21049: anon page @0804a004 (W)

21049: anon page @0804d00c (W) – запись меток

21049: fsync(1)

21049: anon page @0804b000 (R)

21049: anon page @0804c000 (R) – обращение к выделенной области

21049: fsync(2)

21049: fsync(0)

21049: anon page @08050014 (W) – выделение следующих 12 кб (запись метки)

21049: fsync(1)

21049: anon page @0804e000 (R)

21049: anon page @0804f000 (R) – обращения к выделенной области

21049: fsync(2)

…

21049: brk(0808f000) – очередной вызов malloc(), расширяем сегмент данных

21049: brk -> 134803456 (0808f000)

21049: anon page @0806e064 (W)

21049: fsync(1)

21049: fsync -> -22 (ffffffea)

21049: anon page @0806c000 (R)

21049: anon page @0806d000 (R)

…

Таким образом, видно, что malloc выделяет память блоками по 128 с небольшим кб при помощи вызова brk(). Рассмотрим, что происходит при увеличении размера запроса.

3) Запрашиваем последовательно 4, 8, 12, 16К, и т.д., обращаясь в цикле ко всем страницам. При этом, как только размер выделения превышает 128К, malloc выделяет память уже не из области сегмента данных программы (расширяемого вызововм brk()), а при помощи mmap(), после чего free() его освобождает последующим munmap():

789: mmap (00000000, 139264, rw-, PRIVATE | ANON, fd -1, @f019a000)

789: mmap -> -1210519552 (b7d8f000)

789: anon page @b7d8f004 (W)

789: fsync(1)

789: anon page @b7d90000 (R)

…

789: anon page @b7db0000 (R)

789: fsync(2)

789: munmap (b7d8f000, 139264)

789: munmap -> 0 (00000000)

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

3) Третий пример запрашивает память куда большими блоками, увеличивающимися по 100 Мб. При отключенном overcommit'e память быстро заканчивается, и очередной mmap возвращает ENOMEM:

1536: mmap (00000000, 629149696, rw-, PRIVATE | ANON)

1536: mmap -> -12 (fffffff4)

1536: anon page @b7e06de0 (R)

1536: brk(00000000)

1536: brk -> 134520832 (0804a000)

1536: brk(2d86b000)

1536: brk -> 134520832 (0804a000)

1536: mmap (00000000, 629280768, rw-, PRIVATE | ANON)

1536: mmap -> -12 (fffffff4)

1536: mmap (00000000, 2097152, rw-, PRIVATE | ANON)

1536: mmap -> -1212555264 (b7b9e000)

1536: munmap (b7b9e000, 401408)

1536: munmap -> 0 (00000000)

1536: munmap (b7d00000, 647168)

1536: munmap -> 0 (00000000)

1536: anon page @b7c00008 (W)

1536: mmap (00000000, 629149696, rw-, PRIVATE | ANON)

1536: mmap -> -12 (fffffff4)

Библиотека libc при этом пытается сначала выделить ту же память при помощи вызова brk(), затем снова при помощи вызова mmap(), но уже несколько меньший объем, однако и эти вызовы проходят неудачно.

4) Включим overcommit. Теперь, пока программа не обращается ко всем страницам из выделенного региона, а лишь к некоторым (не расходуя при этом всю физическую память), выполнение проходит нормально, и вызов mmap() успешно выделяет блоки памяти, значительно превыщающие объем свободной оперативной памяти (порядка 600 M):

2515: mmap (00000000, 996151296, rw-, PRIVATE | ANON)

2515: mmap -> 2089299968 (7c883000)

2515: anon page @7c883004 (W)

2515: fsync(1)

2515: anon page @8b603008 (R)

2515: anon page @9a383008 (R)

2515: anon page @a9103008 (R)

2515: fsync(2)

2515: munmap (7c883000, 996151296)

2515: munmap -> 0 (00000000)

В данном примере вызов mmap() выделяет 900М, из которых мы обращаемся лишь к четырем страницам.

5) При попытке попытаться обратиться ко всем страницам из выделенного региона, очень скоро память исчерпывается и возникает ситуация, называемая OOM – Out Of Memory. В этом случае ядро вызывает функцию oom_kill(), которая выбирает процесс-жертву для уничтожения, основываясь на расходах памяти, времени работы, приоритете и т.п., и убивает выбранный процесс, с целью освободить память. При этом в журнал отладочных сообщений ядра выдается уведомление о том, что сработал oom_kill:

kernel: kwin invoked oom-killer: gfp_mask=0x201d2, order=0, oomkillad

6) Включим теперь файл подкачки. В случае, если объем выделяемого региона превышает размер доступной физической памяти, но меньше суммарного размера ее и файла подкачки, страницы из региона сначала выделяются по мере обращения к ним, затем старые начинают выгружаться в swap‑файл, после чего на втором цикле считывания происходит их подкачка оттуда:

19225: anon page @b7418bb0 (R)

…

19225: anon page @b7602893 (R)

19225: swapfile page @0ae1507c (R)

19225: swapfile page @0d8cb0e6 (R)

…

19225: swapfile page @0af146b0 (R)

7) Системные вызовы mlock()/mlockall() делают невыгружаемой определенную страницу виртуальной памяти процесса или все его страницы – текущие и / или выделенные в будущем, в зависимости от передаваемых в вызов mlockall() флагов.

Сделаем в начале выполнения программы невыгружемыми все страницы, выделяемые в будущем, после чего выделяем блоки по 12 кб (не освобождая):

13749: brk(00000000)

13749: brk -> 134520832 (0804a000)

13749: brk(0806e000)

13749: anon page @0804a000 (W)

…

13749: anon page @0806c000 (W)

13749: anon page @0806d000 (W)

13749: brk -> 134668288 (0806e000)

…

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

Таким образом, можно сделать следующие выводы:

1. При выделении памяти ядро не выделяет сразу все физические страницы (если в mmap() не был передан флаг MAP POPULATE или страницы процесса не были заблокированы в физической памяти вызовами mlock[all]() – в этих случаях страницы всего региона подгружаются сразу)

2. Для выделения небольших объемов памяти библиотека libc расширяет сегмент данных программы вызовом brk(), для запросов, бОльших 128К – использует mmap().

1. Overcommit является довольно мощным средством, позволяющим выделять гораздо больше виртуальной памяти, чем доступно на самом деле, при условии использования лишь доступного ее объема (данная возможность может быть полезна для различных научно-инженерных приоложений). Однако, в случае, если реально затребованная память превысит суммарноый объем доступной и файла подкачки, возникнет критическая ситуация нехватки памяти. Заключение

В рамках данной работы были исследованы вопросы, связанные с разработкой драйверов под OS Linux, работой ядра Linux с виртуальной памятью и перехватом системных вызовов.

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

Было произведено исследование механизма выделения памяти в ядре Linux и библиотеке libс, исследована технология overcommit.

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

3. Список использованной литературы

1. Jonathan Corbet. Linux Device Drivers, 3rd Edition.

2. Роберт Лав. Разработка ядра Linux, 2-е издание.

3. Peter Salzman. The Linux Kernel Module Programming Guide, 3rd Edition.

4. Клаудия Родригес. Азбука ядра Linux.

5. Исходники ядра и документация к ним.

3. Приложения

   2. Код драйвера

      1. mmon.c

/*

* Main module and entry point of memmon.

*/

#include

#include

#include

#include

#include «common.h»

#include «watch-pids.h»

#include «mm-fault.h»

#include «events.h»

#include «syscalls.h»

/*** Internal data ***/

/*

* procfs directory entry

*/

struct proc_dir_entry *procdir = NULL;

/*

* Init entry point

*/

static int __init init(void)

{

int ret = – EBUSY;

procdir = proc_mkdir (PROCDIR, NULL);

if (! procdir)

goto out;

if (! init_watch_pids())

goto out_procdir;

if (! init_events())

goto out_watch_pids;

if (! capture_syscalls())

goto out_events;

capture_mmfault();

return 0;

out_events:

fini_events();

out_watch_pids:

fini_watch_pids();

out_procdir:

remove_proc_entry (PROCDIR, NULL);

out:

return ret;

}

module_init(init);

/*

* Exit point

*/

static void __exit exit(void)

{

release_mmfault();

restore_syscalls();

fini_events();

fini_watch_pids();

remove_proc_entry (PROCDIR, NULL);

}

module_exit(exit);

/*** Module info ***/

MODULE_LICENSE («GPL»);

MODULE_AUTHOR («Ivan Korotkov»);

MODULE_DESCRIPTION («Linux Virtual Memory Monitor»);

1. events.h

/*

* Events ringbuffer.

*/

#ifndef MEMMON_EVENTS_H

#define MEMMON_EVENTS_H

/* Filename in procfs directory */

#define EVENTS_ENTRY «events»

/* Types of events */

enum memmon_event_type

{

NOTUSED = 0, /* to prevent treating zero-filled region as event struct */

MMAP2,

MUNMAP,

MREMAP,

MLOCK,

MUNLOCK,

MLOCKALL,

MUNLOCKALL,

BRK,

FSYNC,

ANON_PF,

SWAP_PF,

FILE_PF,

SYSCALLRET

};

/*

* Struct describing each event

*/

struct memmon_event

{

/* Type */

enum memmon_event_type type;

/* Caller PID */

pid_t pid;

Характеристики

Список файлов курсовой работы