размер кучи в линуксе

[rendom]

Где у линукса в /proc/[pid]/* лежит размер аллокированной кучи? Чего-то я не пойму...

Существует другой способ получить текущий размер кучи? Функцией какой-нибудь сишной, например.

mmap() вроде бы с кучей не работает. А где она память аллоцирует?

[serzh-z]

Никак. По крайней мере без танцев с бубном это не представляется возможным. С помощью sbrk(0) можно получить край хипа, и потом, теоретически, можно посчитать его размер...

[oav]

Где у линукса в /proc/[pid]/* лежит размер аллокированной кучи? Чего-то я не пойму...

Существует другой способ получить текущий размер кучи? Функцией какой-нибудь сишной, например.

mmap() вроде бы с кучей не работает. А где она память аллоцирует?

зачем?

[serzh-z]

Сишной функции, разумеется, не существует - так как стандарт не требует присутствия стека и/или хипа.

Любопытно - для какой цели это вам необходимо?

[Skladnoy]

Полагаю, для того чтобы смотреть как она растет (или не растет) За фрагментацией следить, к примеру...

Кстати, действительно интересно

[rendom]

Всяким алгоритмам умным, которые памяти много аллоцируют, нужно знать, сколько они этой памяти уже позабирали, чтобы иногда чего-нибудь в этой памяти заоптимизировать, например.
У солярки, между прочим, есть структурка pstatus_t в которую из файла /proc/[pid]/status можно считать данные и pstatus_t.pr_brksize будет размером кучи. А в Линуксе такого нет, да?

[serzh-z]

Да. Портабельного и готового решения нет. Лишь костыли. Можно реализовать обертку вокруг распределителя (malloc, например) и в ней подсчитывать сколько чего выделено.

[rendom]

А если из process image size чего-нибудь вычесть, например какой-нибудь code segment size, получим размер кучи?

[serzh-z]

Нужно еще учесть размер стека.

[rendom]

мониторю размер кучи на солярке и аиксе. Аллокирую память, смотрю размер кучи, освобождаю память. А она не освобождается. Не уменьшается. Только увеличивается если больший объем аллокировать. sbrk(0) точно также себя ведет. Какой механизм у этой кучи?

[vr13]

а чем плох /proc/<pid>/stat* и /proc/<pid>/maps?
по-моему, куда уж детальнее..

[serzh-z]

по-моему, куда уж детальнее..

А где здесь размер хипа?

[sdk]

Блин, я не в силах удержаться .
Но когда я читаю название этой темы...
У меня постоянно проскакивает ассоциация, что ее написал кто-то, кто очень боится линукса .

Сорри за оффтопик.
Надо отправлять поскорее, пока не проснулась моя модераторская совесть и я не удалил собственное сообщение .

[zov]

Аллокирую память, смотрю размер кучи, освобождаю память. А она не освобождается. Не уменьшается.

Память освобождается с какого места кучи? При освобождении "с конца" sbrk(-size) в linux работает.

[zov]

Существует другой способ получить текущий размер кучи? Функцией какой-нибудь сишной, например.

malloc_stats()

[rendom]

Блин, я не в силах удержаться .
Но когда я читаю название этой темы...
У меня постоянно проскакивает ассоциация, что ее написал кто-то, кто очень боится линукса .

Да не, я всего боюсь Но уже привык. Приходится код проверять на пяти платформах. 3 юникса + linux + winnt. И еще у каждой операционки версии есть... иногда только тоска подкрадывается незаметно и начинает хотеться куда-нибудь от всего этого спрятаться. Последний раз такое было когда стал разбираться с организацией многопоточности и дампом стека потока. Хорошо что появились неотложные дела, и все эти стеки и потоки пришлось отложить в сторону на время

[rendom]

malloc_stats()

Оооо!!! супер!!! структура mallinfo в malloc.h - это как раз то что мне нужно. /ушел искать подобное для соляриса хп и аикса/

[rendom]

Искать долго не пришлось. Все работает. Только солярис почему-то засунул mallinfo() в libmalloc, тогда как все остальные платформы совершенно правильно сделали это в libc. Ну вот зачем спрашивается сану понадобилось извращаться.

[serzh-z]

Ну вот зачем спрашивается сану понадобилось извращаться.

Вероятно - это отголоски "войны юниксов", хотя может потому, что mallinfo() - расширение GNU, и, соответственно, является частью GNU libc...

[rendom]

Поспешил я с быстрым ответом. Пьюрифайные билды показали, что в линуксе функция mallinfo() реализована криво. Purify ругается на нее FMR и ABR. А если вызывать раз 30 подряд, то в какой-то момент прога вываливается в кору вот с таким стеком:

_p2014static [rtlib.o]
mALLINFo [libc.so.6]
mallinfo [libc.so.6]
voMemoryUsed [mypsinfo.c:59]
memUsage [mypsinfo.c:133]
main [mypsinfo.c:33]

А какие еще есть варианты? Вместо mallinfo()

[serzh-z]

Вернуться к началу и все же реализовать свою обертку вокруг malloc(), которая будет считать сколько она уже выделила.