Як Uniux працює з пам'яттю

unsigned long context;

unsigned long start_code, end_code, start_data, end_data;

unsigned long start_brk, brk, start_stack;

unsigned long arg_start, arg_end, env_start, env_end;

unsigned long rss, total_vm, locked_vm;

unsigned long def_flags;

unsigned long cpu_vm_mask;

unsigned long swap_cnt; /* number of pages to swap on next pass */

unsigned long swap_address;

/*

* This is an architecture-specific pointer: the portable

* part of Linux does not know about any segments.

*/

void * segments;

};

Відразу зауважуємо, що крім цілком зрозумілих покажчиків на початок даних (start_code, end_code ...) коду і стека є покажчики на дані відображених файлів (mmap). Це треба сказати особливість Linux - тягти в себе всі що тільки можна. Може бути це і добре, але з іншої сторони так розбазарюватися пам'яттю (згадаємо ще буфера введення/висновку при файловій системі, що теж будуть їсти всі нову пам'ять поки вона є) Даний підхід може негативно відбитися на стабільності системи, адже для запуску якогось життєво необхідного процесу може знадобитися час на звільнення зайвих кешей. Простенька перевірка на утрату вільної пам'яті: уведіть команду "cat /dev/mem >/image " і подивитеся скількох вільних пам'ятей після цього залишилося. Якщо вам це не подобається, то звернете погляд на функцію invalidate_inode_pages(* struct_inode), що звільняє сторінковий кэш для даного файлу.

При будь-якім відкритті файлу, він відразу ж відображається в пам'ять і додається в сторінковий кэш. Реальний же запит на відображення файлу тільки повертає адреса на вже скешированные сторінки.

На рівні процесу робота може вестить як зі сторінками напямую, так і через абстрактну структуру vm_area_struct

struct vm_area_struct {

struct mm_struct * vm_mm; /* VM area parameters */

unsigned long vm_start;

unsigned long vm_end;