Возможность работы с большими обьёмами памяти определяется настройками ядра, которые задаются до его компиляции и это прямо не связано с версией релиза RH Linux, а только с версией ядра. В 7.3 ядро 2.4 и там можно использовать 64Gb.
Если конфигурирование ядра тяжёлая для вас задача, тогда при инсталяции RH Linux в опциях устанавливаемых программ необходимо выбрать тип ядра с поддержкой большой памяти. Соответственно при загрузке ОС Linux в меню будет несколько строк.
Вот статья , в которой рассказывается, как Linux работает с памятью:
http://www.opennet.ru/base/dev/linuxmem.txt.html
Вот выдержки из статьи кому лень ходить:
Stanislav Ievlev,
inger@linux.ru.net
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
Случилось мне однажды поинтересоваться, как же ядро работает с самым
дорогим, что у него есть, с оперативной памятью. Первые попытки
разобраться с налету, что и как ни к чему не привели. Не все так
просто как хотелось бы. Отовсюду торчат концы, вроде все ясно, но как
связать их воедино...
...........................................
Итак, в основе всего лежат страницы памяти. В ядре они описываются
структурой 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 развивается очень быстро и не всегда
предсказуемо.
