Доступная физическая память....

А ограничения на ресурсы нет?

Заранее извиняюсь за наивный вопрос, но -- иногда бывает...

И какая политика overcommit (cat /proc/sys/vm/overcommit_memory)? Не совсем понимаю, как в Линуксе может "провалиться" такой вызов. MAP_NORESERVE должен, по идее, просто привести к segv при записи, если памяти не хватает.

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

хочу только сказать, что MAP_NORESERVE не будет принят во
внимание при strict overcommit (overcommit_memory == 2).

по вопросу о том, как узнать сколько "свободной" памяти.
в данном случае вы можете глянуть на mm/mmap.c:__vm_enough_memory()
и сделать то же самое, вся информация доступна через /proc.

но проще, мне кажется, просто сделать mmap() и проверить
код возврата.

> cat /proc/sys/vm/overcommit_memory
0

Нет, ограничений на ресурсы нет. Еслы вы имеете ввиду ulimit, то

> ulimit -a
core file size (blocks)     0
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
max locked memory (kbytes)  unlimited
max memory size (kbytes)    unlimited
open files                  1024
pipe size (512 bytes)       8
stack size (kbytes)         unlimited
cpu time (seconds)          unlimited
max user processes          8189
virtual memory (kbytes)     unlimited

Но всё-таки, вот sysconf(_SC_AVPHYS_PAGES) говорит, что памяти -
завались, 30 мб. Как же воспользоваться этой информацией, и как
выделить получить в своё распоряжение некоторый регион страниц, не
опасаясь "провала" mmap?

Хорошо, спасибо. Покопаюсь в ядре.

> Но всё-таки, вот sysconf(_SC_AVPHYS_PAGES) говорит, что памяти -
> завались, 30 мб.

знать бы, что делает sysconf(_SC_AVPHYS_PAGES).
очень это смутное понятие, свободная память.

вы еще можете глянуть на sys_sysinfo(struct sysinfo*).
я думаю, sysconf() ее использует.

может, все-таки у вас действительно фрагментировано
адресное пространство? посмотрите /proc/self/maps.

потому что не найти 128K на 2Gb машине - это странно.

какое ядро? там, вроде бы было полно ошибок c
get_unmapped_area(), может в этом дело.

> > cat /proc/sys/vm/overcommit_memory
> 0

ну попробуйте 1 (OVERCOMMIT_ALWAYS).

Ядро - 2.4.19.

Гм, я смотрел, что делает sysconf(_SC_AVPHYS_PAGES). Это просто
значение free из /proc/meminfo, без прибавки cached и buffers...

OVERCOMMIT_ALWAYS попробую, спасибо.

> Гм, я смотрел, что делает sysconf(_SC_AVPHYS_PAGES). Это просто
> значение free из /proc/meminfo, без прибавки cached и buffers...

тогда это не более информативно, чем читать датчик случайных
чисел :)

но! если у вас даже во free болтается 30Mb, то ищите проблему
в самом процессе, который не получает 128K. разве что много
памяти commited другим процессам, OVERCOMMIT_ALWAYS должен
это решить.

что там meminfo про Committed_AS говорит?

странно...

а у меня в meminfo нет Commited_AS :)

> а у меня в meminfo нет Commited_AS :)

блин, сорри, вы же писали, что у вас 2.4

тогда overcommit вообще не при чем, если 30Mb в free.

errno какой?

errno == ENOMEM

2jek_ :

> errno == ENOMEM

Там, вроде, были ограничения на макс. число ммаппингов. Как раз эта ошибка возвращается. Может, оно?