Ограничения mmap() QNX4.25

[mgb14]

Здравствуйте!

В связи с тем, что памяти в компьютерах становится все больше - появляется желание ее использовать
Однако существуют какие-то недокументированные ограничения. Если выделять для разделяемой памяти куски ОЗУ десятками/сотнями мегабайт, то ,несмотря на то что sin показывает наличие гигабайтов свободной памяти, mmap (или ltrunk) возвращает ENOMEM. Во вложении исходный код(.с), исполняемый модуль(proba1), bat-файл для запуска тестирования (.bat) и текстовый вывод при 10 последовательных попытках mmap различного размера памяти (от 10 до 300Мб). Выполнялось на машинах с 4Гб.
Есть ли какие-нибудь определенные лимиты и можно ли их увеличить?

[Сергей Новоселов]

Похоже, это проявление проблемы, описанной в http://forum.kpda.ru/index.php/topic,419.msg8722.html#msg8722. В качестве решения предлагается пересборка ядра с опцей -S.
В документации никакой информации по максимальным значениям нет и то, как эти опции связаны с числом процессов, использующих mmap, тоже непонятно. Опытным путем установлено,
что с -S 8192 7168 ядро работает (при увеличении отказывается загружаться либо вываливается с дампом). Это помогает немного увеличить лимит используемой разделяемой памяти, но не кардинально.

Речь идет вроде про некие дескрипторы сегментов, но как посмотреть, сколько из них свободно/занято, не ясно. Для меня это вопрос остается одной из загадок QNX4

[deadarcher]

Обратитте внимание на полную сумму удачно "смапленных" участков памяти - 1.073.741.824
Причем не важно одним куском "смапленно" или в несколько итераций.
Видимо больше гигабайта не можно одному процессу выделить 

[Андрей Панченко]

Здравствуйте!

Ваш случай может быть проявлением двух особенностей организации памяти QNX 4.

Во-первых, в QNX4 есть общесистемный ресурс (виртуальная память), отображаемый в выводе sin info. Этот ресурс отражает работу Proc с MMU и представляет собой количество доступных записей в TLB (в выводе sin info данная информация представляется в поле Virtual в байтах). Изначально этот ресурс устанавливается исходя из объёма физической памяти, но во время работы может быть увеличен до 4Гб. Этот объём виртуальной памяти распределяется между всеми программами. Виртуальная память расходуется как при создание общей памяти в /dev/shmem так и при её отображении в пользовательскую программу. Таким образом исчерпание виртуальной памяти может произойти раньше исчерпания физической.

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

Таким образом скорее всего вы столкнулись с особенностями организации памяти в QNX4. Возможности без внесения изменений в код Proc повлиять на организацию и алгоритмы работы с описанной виртуальной памятью нет.

[Сергей Новоселов]

Спасибо за развернутый ответ!

Т.е., если я правильно понял, для системы с точки зрения использования оперативной памяти,
нет разницы между выделением в куче через malloc и shm_open/mmap? Если 10 процессов вызвали mmap области памяти размером 1Мб, то система израсходует все равно 10Мб виртуальной памяти?

И какая все-таки связь между объемом используемой разделяемой памяти и монтированием файловых систем (имеется в виду Fsys.umass)?

[deadarcher]

Вот вывод sin free сразу после загрузки (с последним ядром, где -Е0 можно задать)
24576
8192
151552
53248
2909M
28672

Вопрос: можно ли сказать про кусок памяти размером 2909М что он непрерывный или нет ?
Потому что имея даже такой кусок свободной памяти, использовать его через shm_open/mmap не получается. Только 1гигабайт.
(Через malloc потом попробую)

[Андрей Панченко]

deadarcher: sin free отображает фрагменты физической памяти. С кодом из первого сообщения ограничения в 1Гб не наблюдается. Ограничение в 1Гб будет наблюдаться при использовании malloc().

[Андрей Панченко]

Сергей, да израсходуется 10Мб общесистемного ресурса виртуальная память, но 1Мб физической памяти.

[deadarcher]

Андрей, скажите пожалуйста, а почему sin net показывает 3220.7M памяти, хотя виртуальной машине выделено 4096Мб ? (3700 на реальной машине с 16Гб памяти)
И да, через malloc() выделить больше 1Гб не получилось, а через последовательноть shm_open/mmap удалось выделить примерно 1.57Гб (кусками по 100Мб).
(Понятно, что в реальности такие объемы выделять под QNX4 не будем)

[Андрей Панченко]

QNX4 получает карту памяти через прерывание BIOS (в пределах 4Гб). Таким образом различие показаний на виртуальной и реальной машине связано с различиями в реализации BIOS.

[Андрей Сеньков]

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

Глобальная таблица дескрипторов (GDT) является аппаратно зависимой таблицей, определяющей глобальные сегменты системы. Данной таблицей управляет Proc32. Существует ограничение на размер таблицы в 64К. Поскольку размер записи в таблице составляет 8 байт, получается максимум  8192 дескриптора (нулевой дескриптор служебный). При этом, дескрипторы LDT, которые описывают локальные таблицы процессов, должны размещаться в глобальной таблице (GDT). Соответственно, когда значения gdts и ldts задаются через опцию Proc32 -S их сумма не должна превышать 8192.
Если быть более точным, то при использовании опции -S gdts ldts расчёты выполняются по следующему алгоритму:

 num_gdts = 32 + num_proc + gdts
 if (num_gdts + ldts > 8192)
        num_gdts = 8192 - num_ldts;

где,  num_proc - количество процессов (по умолчанию 500, может быть изменено через опцию  Proc32 -p)

Таким образом, чтобы получить максимальное количество глобальных сегментов необходимо учесть описанный выше алгоритм и подобрать ldts в соответствии с максимальным количеством процессов, которые могут исполняться у вас в системе (наиболее безопасным можно считать соотношение ldts = кол-во процессов * 6).

Пример значений, опции -S
Proc32 -S 6660 1000
Proc32 -S 5660 2000

QNX4 не предоставляет возможности получить информацию о количестве занятыx/свободных глобальных дескрипторов. Команда sin gdt выводит поля таблицы GDT, причем, при выводе отбрасывает пустые поля, но при этом выводит поля которые ранее использовались, но были освобождены.
Для того, чтобы получить примерную оценку количества занятых дескрипторов можно выполнить следующую команду:
# sin gdt | grep -v "00000000" | wc -l

[deadarcher]

Спасибо за ответ. Предлагаю его внести в FAQ чтобы не потерялся.

[Олег Большаков]

Добавил вопрос про Proc32 -S gdts ldts в FAQ по QNX.

[Сергей Новоселов]

Андрей, большое спасибо за ответ, теперь стало гораздо понятнее!
Но мне остались неясными следующие моменты:
1. По приведенному алгоритму получается, что если (num_gdts + ldts) <= 8192, то параметр ldts никак не учитывается. Так ли это?
2. Какие параметры используются системой по-умолчанию, если опцию -S не указывать?