LINUX.ORG.RU
ФорумTalks

Любителям firefox: аллокатор из openbsd


0

0

Осуществлена попытка портирования аллокатора malloc из openbsd на linux с целью уменьшить потребление памяти (точнее, её фрагментацию) такими программами, как firefox.

Скачать подправленный исходник можно здесь: http://mr.himki.net/OpenBSD-malloc.c

Собирать так: gcc -shared -fPIC OpenBSD-malloc.c -o malloc.so, запускать так: LD_PRELOAD=/path/to/malloc.so firefox

Это первая версия портирования и работает нестабильно (а на некоторых компьютерах вообще не работает).

Приглашаются желающие протестировать и доделать.

★★

P.S. Сам я не программист. Так что повторю снова: была бы кстати помощь профессиональных программистов.

P.P.S. И всё-таки спасибо тебе, zov :)

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

Это, конечно, так... Жалко, что до сих пор не нашёлся _программист_, который бы пытался это сделать.

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

Под slackware 10.2 работает, память возвращает как надо.

Еще один повод заткнуться любителям критиковать mozilla за отжор памяти.

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

ALT Linux Master 2.4 (Citron) , работает.

на старте RSS=20M, с открытыми ~30 табами 60M, закрыли все и оставили один таб - 30M.

Кэши включены.

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

Вот это самое нехорошее. В этом месте он вообще-то падать должен, но это в malloc было скомментированно.

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

на буке п3 с 198мег рамы несколько напряжно было работать, под Слакварью. Приходилось раз в день перезапускать. С 256 мегами уже луче гораздо.

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

> Вот это самое нехорошее. В этом месте он вообще-то падать должен, но это в malloc было скомментированно.
Не падает пока. Попробую погонять подольше.

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

В смысле, если бы не было скомментировано, то в принципе падало бы, как и должно.

Особенно часто выводится на тяжёлых сайтах типа sovsport.ru. Возможно, это от плугинов может также зависеть -- надо потестировать.

В общем, чувствую, тут ещё разбираться и разбираться... :)

mr ★★
() автор топика

Slackware 10.2
полет нормальный.
смотрю на консоль-пока никаких
варнингов,ерроров и прочего *.

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

Народ, кто тут мозиллу не выключает неделями - оченно рекомендую.

Потребление памяти с openbsd-alloc не растет, после закрытия лишних страниц RSS возвращается к 20-30M.

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

LD_PRELOAD=/tmp/libopenbsd-malloc.so startkde

KDE 3.5.2, slackware 10.2. *** P1/64M RAM !!! ***

Вполне юзабельно. Нет роста потребления памяти в konqueror, соответственно нет постепенного залезания в своп. Открыл наугад 15-20 табов в konqueror, его VM size выросла до где-то 40M, оставляем один этот таб - вернулись к 20M. Параллельно запущен firefox 1.5 c 30-40 табами. закрываем их - тоже возвращается где-то к 20M.

OpenBSD-шникам и mr респект и уважуха :)

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

однозначно. и надо чтоб на это дело глянул D.-H. или кто другой из соображающих в этом деле...

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

Slackware 10.2 + current (было когда-то slax live CD)

c konqueror вроде работает, а вот с мозиллой (НЕ firefox) Mozilla 1.7.11 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729

LD_PRELOAD=./malloc.so mozilla ERROR: ld.so: object './malloc.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './malloc.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './malloc.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './malloc.so' from LD_PRELOAD cannot be preloaded: ignored.

И падает....

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

странно, у меня не работает: делаю LD_PRELOAD=/tmp/malloc.so firefox и тишина. сам firefox в процессах висит (23M) отьел, а окно не появляется.

dreamer ★★★★★
()

А как это тестировать? В смысле что должно происходить без этого аллокатора и с ним?

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

С обычным glibc аллокатором память системе не возвращается после закрытия табов, а с этим -- по большей части возвращается.

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

>однозначно. и надо чтоб на это дело глянул D.-H. или кто другой из соображающих в этом деле...

Было бы хорошо, чтобы они не только взглянули, но и довели бы это дело до ума. Блин! :)

mr ★★
() автор топика

Ой, в calloc я забыл return поставить, пардон :)). Но проблема не в этом, а в чём-то другом, на самом деле.

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

Аналогичное сыпется на консоль, только лиса потом все-таки запускается...

user_undefined
()
Ответ на: комментарий от VictorGr

Если кратко, то glibc malloc предназначен для 1. максимальной скорости аллокаций 2. минимального потребления памяти в _простых_ программах, но он не идеален по части фрагментации памяти.

Этот вопрос уже не раз обсуждался. Напр., товарищем zov на linuxforum.ru. У меня на homepage тоже кое-что написано про это.

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

Давайте, что ли, пообкашляем, так ли все это...

В прочитал рассуждения на странице mr.

Ок, все так. Но существуют некоторые теоретические исследования, показывающие, что та стратегия, что принята в glibc malloc, оптимальна. Кто знает точные ссsлки, киньте, плз. -- вроде, Кнут этим занимался? Впрочем, наверняка в его книге это есть.

Просто у меня есть подозрение, что, за исключением того, что _отображаемый_ размер кучи растет, никаких физических следствий быть не должно. В частности, если описанные механизмы приводят к залезанию в своп, то это -- баги в ядре, а не в glibc malloc.

(Я даже не думал над этим, просто, соображения "навскидку").

Кстати, написАть аллокатор на mmap -- дело пары часов (с отладкой и тестированием).

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

>Но существуют некоторые теоретические исследования, показывающие, что та стратегия, что принята в glibc malloc, оптимальна.

Среди короткоживущих программ или аллокаторов, основанных на brk -- видимо, да.

На конкретном примере firefox убедились, что аллокатор openbsd память системе отдаёт, а glibc -- нет.

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

Как это не должно?? Фрагментация памяти есть, память вообще может отдаваться системе целыми страницами -- принцип таков.

mr ★★
() автор топика

Просто размышление неопытного человека:а ведь все компилят с разными флагами оптимизации...

Motiv_studenta ★★
()
Ответ на: комментарий от Die-Hard

Принципы размещения переменных в памяти описан в самом dlmalloc: http://gee.cs.oswego.edu/pub/misc/malloc.c

Был ещё документ это описывающий...

>Кстати, написАть аллокатор на mmap -- дело пары часов (с отладкой и тестированием).

В том то и дело, что для программ типа firefox нужны более сложные алгоритмы размещения переменных в памяти, чем просто линейное -- иначе точно не будет преимущества перед brk-based mallocs. Оказалось, что в openbsd malloc эти алгоритмы хорошие.

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

2mr:

> ...память вообще может отдаваться системе целыми страницами -- принцип таков.

Да, но зачем ее вообще отдавать-то?

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

> В частности, если описанные механизмы приводят к залезанию в своп, то это -- >баги в ядре, а не в glibc malloc.

Почему баг?
допустим glibc держит свободную страницу у себя в пуле,
в отличие от openbsd, если не будет хватать памяти, то т.к.
она не используется то ядро ее поместит в своп.

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

s/она не используется то ядро ее поместит в своп/
она не используется, но принадлежит адресному пространству,
то ядро ее поместит в своп/g

fghj ★★★★★
()
Ответ на: комментарий от Die-Hard

То есть, если я 1000 раз закажу кусок по 2048 страниц и в каждый кусок засуну по одному символу, то _физически_ разместиться должно только 1000 страниц, хотя VM будет 2048000*(размер страницы) байт.

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

Если после длительного сеанса firefox занимает в памяти 200M, а реально используется 40M, то это очень не хорошо. И при этом данные ~ равномерно разбросаны по всей этой области => ничего скинуть в своп не получится!

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

2fghj:

> допустим glibc держит свободную страницу у себя в пуле, в отличие от openbsd, если не будет хватать памяти, то т.к. она не используется то ядро ее поместит в своп.

Если на страницу никто ничего не писАл, то ядро не должно отправлять ее в своп. Ибо она вообще не распределена.

Теоретически, вроде, показано, что количество актуально свободных страниц, которые уже были, тем не менее, распределены, не должно быть большим.

Die-Hard ★★★★★
()
Ответ на: комментарий от mr

mr:

Такая ситуация может возникнуть только при очень неграмотном управлении памятью.

Например, если _систематически_ делать все free() после всех malloc(), или злоупотреблять realloc()'ом.

Возможно, Огнелис так и поступает, конечно...

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

Вообще не понимаю причину спора. Суть проблемы очевидна? Очевидна! То, что openbsd аллокатор её в целом решает, очевидно? Очевидно! Значит надо его переносить на линукс.

Никто ведь не требует, чтобы он становился дефолтным аллокатором для линукса! Просто его можно использовать в программах типа firefox, konqueror и т.д.

mr ★★
() автор топика
Ответ на: комментарий от Die-Hard

Я так понимаю, что это особенность идеологии программирования для мозиллы. И вообще web-браузинг подразумевает случайные как размер, так и порядок alloc/free. Конечно, если бы оно было изначально написано с какими-нибудь "memory pools" (как в apache), то проблемы не возникло. Но жизнь в режиме "если" не работает :-/

mr ★★
() автор топика
Ответ на: комментарий от Die-Hard

>Вроде, доказано, что это -- оптимально

оптимально по каким параметрам, скорости или использованию памяти?

fghj ★★★★★
()
Ответ на: комментарий от Die-Hard

>Если на страницу никто ничего не писАл, то ядро не должно отправлять ее в >своп.

а почему никто не писал?

кто-то выделил, пописал, освободил,
glibc держит ее у себя в пуле,
откуда ядро знает что об этой странице можно забыть и засовывать ее в своп?

fghj ★★★★★
()
Ответ на: комментарий от Die-Hard

>Например, если _систематически_ делать все free() после всех malloc(), или злоупотреблять realloc()'ом.

>Возможно, Огнелис так и поступает, конечно...

вывод malloc_stats():

https://bugzilla.mozilla.org/show_bug.cgi?id=324081#c17

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

>кто-то выделил, пописал, освободил, glibc держит ее у себя в пуле, откуда ядро знает что об этой странице можно забыть и засовывать ее в своп?

забыть (MADV_DONTNEED) =/= засунуть в своп!

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