Выделение памяти большими кусками

http://stackoverflow.com/questions/4401912/linux-contiguous-physical-memory-f...

Вот тут говорят, что хрен.

If you say «we need to do this from User Space» - without anything going on in kernel-space it makes little sense - because a user space program has no way of controlling or even knowing if the underlying memory is contiguous or not.

Есть подозрение, что ковыряние в кишках glibc (или чей там аллокатор у тебя используется), может помочь и натолкнуть на какую-нибудь мысль.

Также есть подозрение, что скорее всего без своего ядерного модуля этого не сделать.

Я нихера не понял из вопроса.

у нас на 64-битных платформах таких проблем нет. Выкинь уже своё устаревшее говнецо.

#include <malloc.h>
/* see struct mallinfo description in header file */
printf("mallinfo = %p\n",mallinfo);

и большие куски памяти (под буферы и прочая) лучше сразу выделать через mmap

mmap есть не везде. Плюс во многих системах malloc дёргает mmap, если это оправданно. В glibc, например, такая шняга.

Вот тут говорят, что хрен.

Ты тупой штоли и не различаешь физическую память от виртуальной?

Есть подозрение, что ковыряние в кишках glibc (или чей там аллокатор у тебя используется), может помочь и натолкнуть на какую-нибудь мысль.

так варианта всего 2. либо mmap либо brk.

Я помню, как в досе прерывание, выделяющее память, при передаче ему слишком большого значения возвращало размер самого большого участка, который оно может выделить :)

А вообще malloc выделяет непрерывные участки виртуальной памяти, а не физической, а у каждого процесса таблица страниц своя. Вы до этого выделяли память в этом процессе?

Да в том то и дело, что до этого выделяется. Память уже изрядно фрагментирована.

Тогда печально. Если у вас много связок malloc/free посмотрите в сторону плиточного аллокатора.

А как узнать максимально доступный непрерывный кусок?

Делением пополам, или типа того.

Просишь 2 Гб. Послали - утираешься, вычитаешь из 2 Гб червертушку, и просишь 1.5 Гб. Послали - утираешься, выитчаешь от 1.5 Гб четвертушку, и просишь 1,125 Гб ... так до тех пор, пока не дадут :)

Через 20 попыток от изначально желаемых 2 Гб твои амбиции сдуются до 6,5 Мб. Возможно, будет это даже быстрее, чем парсить содержимое /proc/

При этом точность полученного ответа - 25%.

mmap файл на диске

Система 32 бит или 64 бит? Если 64 - все должно работать. Если 32 - ничего не получится.

mmap есть не везде

из man`а mmap:

The Single UNIX ® Specification, Version 2 Copyright © 1997 The Open Group

а зачем в системах без SUSv2 выделять по 2 Гб памяти ? Это вы форумом ошиблись и пишите под embedded и на такие объёмы там отдельные пляски или там у вас совсем не даже не *nix :)

p.s. mmap is mandatory for U95,U98,XSI,POSIX specifications (http://www.unix.org/version4/GS5_APIs.pdf)

посмотрите в сторону плиточного аллокатора

А можно ссылку на описание, что это?

http://en.wikipedia.org/wiki/Slab_allocation

аааа, так плиточный это слябовый =)

спасибо

ну это мне въелся в голову такой перевод из какой-то книжки по ядру :)