Случилось мне однажды поинтересоваться, как же ядро работает с самым
   дорогим, что у него есть, с оперативной памятью. Первые попытки
   разобраться с налету, что и как ни к чему не привели. Не все так
   просто как хотелось бы. Отовсюду торчат концы, вроде все ясно, но как
   связать их воедино...
...........................................
Итак, в основе всего лежат страницы памяти. В ядре они описываются
   структурой mem_map_t.
...........................................
Уже тут наблюдается определенная навороченность. Множество всяких
   ссылок. Вы не поверите, но все они используются. Одна страница может
   находиться в разных списках, например и в списке страниц в страничном
   кеше и в списке страниц относящихся к отображенному в память файлу
   (inode)
............................................
Отсутствие страницы в памяти обрабатываются ядром особо. Страница
   может или вообще отсутствовать или находиться в области подкачки.
............................................
Сразу замечаем, что помимо вполне понятных указателей на начало данных
   (start_code, end_code ...) кода и стека есть указатели на данные
   отображенных файлов (mmap). Это, надо сказать, особенность Linux -
   тащить в себя все, что только можно. Может быть это и хорошо, но с
   другой стороны так разбазариваться памятью ...(вспомним еще буфера
   ввода/вывода при файловой системе, которые тоже будут кушать все новую
   память пока она есть). Данный подход может негативно отразиться на
   стабильности системы, ведь для запуска какого-то жизненно необходимого
   процесса может потребоваться время на освобождение лишних кешей.
   Простенькая проверка на потерю свободной памяти: введите команду  "cat
   /dev/mem >/image "  и посмотрите сколько свободной памяти после этого
   осталось. Если вам это не нравится, то обратите взгляд на функцию
   invalidate_inode_pages(* struct_inode), освобождающую страничный кэш
   для данного файла.
............................................
Что же в  2 . 4 ?
   
   Добавлена поддержка новой архитектуры памяти NUMA. В противовес
   классической UMA память делится на зоны с разным временем доступа к
   каждой из них. Это очень полезно и для кластерных решений. В связи с
   этим появились новые обертки на функции, новые структуры и найти суть
   стало еще сложнее. Появилась также поддержка памяти до 64Гб.
   
   Раньше для всех файловых систем был один generic_file_read и
   generic_file_mmap в связи с тотальным засасыванием всего подряд в
   память при чтении (различия делались уже только на уровне
   inode->readpage). Теперь появился и generic_file_write. В общем, еще
   пара таких generic и прощай виртуальная файловая система.
   
   Но посмотрим - увидим. Ведь Linux развивается очень быстро и не всегда
   предсказуемо.