LINUX.ORG.RU

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


0

2

Пытаюсь выделить 2 Gb — fail.
2 раза по 1 Gb — success.
Понятно, что фрагментация памяти.
А как узнать максимально доступный непрерывный кусок? Из user-mode.
Смотрел /proc/self/maps — там о регионах ничего нет.
То есть, я оттуда могу получить информацию об общем числе незамапленных регионов, но увидеть непрерывный кусок не могу.

$cat /proc/self/maps
08048000-0804c000 r-xp 00000000 03:01 122897 /bin/cat
0804c000-0804d000 rwxp 00004000 03:01 122897 /bin/cat
0804d000-0806e000 rwxp 0804d000 00:00 0 [heap]
b7e6e000-b7ea0000 r-xp 00000000 03:01 165044 /usr/share/locale/KOI8-R/LC_CTYPE

В области 0806e000 — b7e6e000 размещаются выделяемые гигабайты. Общая сумма области порядка 3 Gb.
Ковыряние в /proc/self/mem может как-то помочь в поиске непрерывного региона?



Последнее исправление: CannyMan (всего исправлений: 1)

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 (или чей там аллокатор у тебя используется), может помочь и натолкнуть на какую-нибудь мысль.

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

DELIRIUM ☆☆☆☆☆
()

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

anonymous
()

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

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

anonymous
()
Ответ на: комментарий от DELIRIUM

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

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

anonymous
()
Ответ на: комментарий от DELIRIUM

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

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

exception13 ★★★★★
()

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

buddhist ★★★★★
()

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

buddhist ★★★★★
()

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

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

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

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

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

Manhunt ★★★★★
()

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

Deleted
()
Ответ на: комментарий от anonymous

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)

MKuznetsov ★★★★★
()
Ответ на: комментарий от user_2190

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

buddhist ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.