[devel] q: glibc malloc s*cks?

[devel] q: glibc malloc s*cks?

[Michael Shigorin]

	Здравствуйте.
Тут нашлось неожиданное применение недавно пробегавшему
http://mr.himki.net/index-alloc.html: в процессе раскапывания
проблемы с время-от-времени замерзающими терминалами под LTSP
(PIII/64M/ATI, diskless) было замечено, что причиной является
распухающий Xorg, которого надувает при хождении по страничкам
с картинками (менее -- с Flash) Firefox.

Примерные цифры RSS Xorg (сборки LTSP4.2u4) при использовании
в качестве среды firefox-1.0.8 из ALC3.0:

* загружен dm -- ~10M
* загружен firefox -- чуть больше 10M
* пяток табов, один с историей до десятка страниц (новостной
  сайт, куча картинок) -- 20--25M
* закрыли браузер -- ~15M

При этом надувается процесс достаточно уверенно и односторонне,
до ~45--50M или когда там начинает заканчиваться память -- за
несколько часов добраться более чем возможно.  Свопа нет и
подключить его запросто не получилось (будто бы в LTSP'шном
ядре не хватает CONFIG_NFS_DIRECTIO -- огребаем при
swapon /своп/файлик/на/nfs: "swapfile has holes").

Пришла мысль попробовать запустить firefox под другим
аллокатором, хотя предполагалось, что запускать надо Xorg
(на терминале, т.е. ещё собирать в схожем с LTSP окружении).

Попробовали.  Оказалось, что помогает __Xorg__ и довольно
радикально -- пока по наблюдениям sinister@ выходит, что:

- в среднем с тем же firefox и теми же страничками Xorg
  потребляет меньше памяти;
- при закрытии таба с историей в firefox на TS
  Xorg на терминале также "сдувается" в некоторой мере;
- при закрытии firefox RSS Xorg возвращается к значению
  до запуска браузера, а не как минимум на несколько Мб большему.

Странно, но факт.

Не будучи в курсе того, как именно выделяется/распределяется
память (и какое происходит взаимодействие с Xorg, а также 
какого тот замерзает, а не пытается высвободить закэшированные
пиксмапы, при нехватке памяти) -- сказали sr@, который кратко
охарактеризовал glibc malloc как "deprecated, поскольку brk()
был объявлен таким ещё около 2.0.29".

Отсюда вопросы.

1) кому ещё интересно тестирование такого malloc()
   -- мож его опакетить для удобства?
2) кому может быть интересно развитие в упоминаемом
   направлении -- с использованием mmap()?
3) интересно ли это команде в дистрибутивном плане?
4) каковы шансы переубедить libc-alpha@ в том, что 
   текущая реализация является рабочей, а не сломанной?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] q: glibc malloc s*cks?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Mon, Jan 15, 2007 at 03:59:34PM +0200, Michael Shigorin wrote:
[...]
> Не будучи в курсе того, как именно выделяется/распределяется
> память (и какое происходит взаимодействие с Xorg, а также 
> какого тот замерзает, а не пытается высвободить закэшированные
> пиксмапы, при нехватке памяти) -- сказали sr@, который кратко
> охарактеризовал glibc malloc как "deprecated, поскольку brk()
> был объявлен таким ещё около 2.0.29".

Скажите sr@, что glibc malloc уже давно использует mmap.
См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html

> Отсюда вопросы.

Вопросы эти исходят из ложной посылки.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] q: glibc malloc s*cks?

[Michael Shigorin]

On Mon, Jan 15, 2007 at 05:13:42PM +0300, Dmitry V. Levin wrote:
> > Не будучи в курсе того, как именно выделяется/распределяется
> > память (и какое происходит взаимодействие с Xorg, а также
> > какого тот замерзает, а не пытается высвободить
> > закэшированные пиксмапы, при нехватке памяти) -- сказали sr@,
> > который кратко охарактеризовал glibc malloc как "deprecated,
> > поскольку brk() был объявлен таким ещё около 2.0.29".
> Скажите sr@, что glibc malloc уже давно использует mmap.
> См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html

Посмотрел в 2.3.5 из 3.0 и 2.5 из сизифа -- отличия, помимо
изменений по тредовой части и обновления копирайтов, для меня
неочевидны; а, хотя нужный кусок процитирован здесь и это 2006:
http://sourceware.org/ml/libc-alpha/2006-03/msg00033.html

Бишь с одной стороны -- давно (<5 лет, судя по winehq)
используется mmap, но с другой -- только недавно он перестал
быть отдельной причиной как минимум тормозов на временных
аллокациях.

> > Отсюда вопросы.
> Вопросы эти исходят из ложной посылки.

Дим, как же тогда пояснить наблюдаемое и изложенное в первом
письме?  Пока костылик, залитый как openbsd-malloc, решил
вполне ощутимую проблему в случае использования 3.0.

Ещё погоняем, но пока похоже на то.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] q: glibc malloc s*cks?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

On Mon, Jan 15, 2007 at 03:59:34PM +0200, Michael Shigorin wrote:

MS> 1) кому ещё интересно тестирование такого malloc()
MS>    -- мож его опакетить для удобства?
MS> 2) кому может быть интересно развитие в упоминаемом
MS>    направлении -- с использованием mmap()?
MS> 3) интересно ли это команде в дистрибутивном плане?
MS> 4) каковы шансы переубедить libc-alpha@ в том, что 
MS>    текущая реализация является рабочей, а не сломанной?

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

Видимо он более грамотно работает в ситуации со множеством выделений
небольших блоков памяти. И вообще-то вполне логично для такой цели
использовать специфический аллокатор.

А если совсем честно, то выделение malloc'ом большого количества маленьких
кусков памяти это мягко говоря свинство.

Давным-давно была хорошая практика для крупных приложений использовать
специфические аллокаторы. Странно что эта практика была полностью забыта.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Программерское: Какие красивые, длинные логи!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] q: glibc malloc s*cks?

[sr]

On Mon, Jan 15, 2007 at 05:13:42PM +0300, Dmitry V. Levin wrote:
> Скажите sr@, что glibc malloc уже давно использует mmap.
> См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html

Агащазблин.

$ echo "int main() { return malloc( 1) ? 0 : 1; }" > 1.c
$ gcc 1.c
$ strace ./a.out
execve("./a.out", ["./a.out"], [/* 49 vars */]) = 0
brk(0)                                  = 0x804a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=62887, ...}) = 0
mmap2(NULL, 62887, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7f82000
close(4)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\232b\1"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=1167868, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f81000
mmap2(NULL, 1173764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xb7e62000
mmap2(0xb7f7b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x119) = 0xb7f7b000
mmap2(0xb7f7e000, 10500, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f7e000
close(4)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e61000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e616c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f7b000, 4096, PROT_READ)   = 0
munmap(0xb7f82000, 62887)               = 0
brk(0)                                  = 0x804a000
brk(0x806b000)                          = 0x806b000
exit_group(0)                           = ?
Process 6119 detached

$ rpm -q glibc
glibc-2.5-alt3

Re: [devel] q: glibc malloc s*cks?

[sr]

On Mon, Jan 15, 2007 at 10:19:21PM +0300, Денис Смирнов wrote:
> Date: Mon, 15 Jan 2007 22:19:21 +0300
> From: Денис Смирнов <mithraen@altlinux.ru>
> To: devel@lists.altlinux.org
> Subject: Re: [devel] q: glibc malloc s*cks?
> 
> On Mon, Jan 15, 2007 at 03:59:34PM +0200, Michael Shigorin wrote:
> 
> MS> 1) кому ещё интересно тестирование такого malloc()
> MS>    -- мож его опакетить для удобства?
> MS> 2) кому может быть интересно развитие в упоминаемом
> MS>    направлении -- с использованием mmap()?
> MS> 3) интересно ли это команде в дистрибутивном плане?
> MS> 4) каковы шансы переубедить libc-alpha@ в том, что 
> MS>    текущая реализация является рабочей, а не сломанной?
> 
> Вообще-то мне кажется что подобный аллокатор есть смысл собрать с _другим_
> именем функций, и собирать отдельные пакеты с использованием именно этого
> аллокетора.
> 
> Видимо он более грамотно работает в ситуации со множеством выделений
> небольших блоков памяти. И вообще-то вполне логично для такой цели
> использовать специфический аллокатор.
> 
> А если совсем честно, то выделение malloc'ом большого количества маленьких
> кусков памяти это мягко говоря свинство.
> 
> Давным-давно была хорошая практика для крупных приложений использовать
> специфические аллокаторы. Странно что эта практика была полностью забыта.

Как раз для софта аля мозилка имеет смысл вообще использовать аллокаторы
типа виндового HeapCreate(), HeapAlloc(), HeapDestroy(). По крайне мере
дырок не будет, хип для следующей большой транзакции заново создать можно
и грохнуть всем скопом, когда не нужно.

Re: [devel] q: glibc malloc s*cks?

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Hi sr!

Monday 15, at 11:38:41 PM you wrote:

<skip>
> Как раз для софта аля мозилка имеет смысл вообще использовать аллокаторы
> типа виндового HeapCreate(), HeapAlloc(), HeapDestroy(). По крайне мере
> дырок не будет, хип для следующей большой транзакции заново создать можно
> и грохнуть всем скопом, когда не нужно.
разве не для этого nspr придумали? :)

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] q: glibc malloc s*cks?

[Michael Shigorin]

On Mon, Jan 15, 2007 at 11:33:03PM +0200, sr@altlinux.ru wrote:
> > Скажите sr@, что glibc malloc уже давно использует mmap.
> > См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html
> Агащазблин.

Скажем так -- "умеет использовать mmap", посмотри "Update in 2006:"
по второй ссылке на libc-alpha@ (или в malloc.c@~1480) для
уточнения нынешнего изменения порога между mmap и brk.

> $ echo "int main() { return malloc( 1) ? 0 : 1; }" > 1.c
> $ gcc 1.c
> $ strace ./a.out
[...]
> brk(0)                                  = 0x804a000
> brk(0x806b000)                          = 0x806b000
> exit_group(0)                           = ?
> Process 6119 detached

$ echo "int main() { return malloc( 2000000 ) ? 0 : 1; }" > 2.c
$ gcc 2.c
2.c: In function 'main':
2.c:1: warning: incompatible implicit declaration of built-in function 'malloc'
$ strace ./a.out 
execve("./a.out", ["./a.out"], [/* 71 vars */]) = 0
brk(0)                                  = 0x804a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0f000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=135213, ...}) = 0
mmap2(NULL, 135213, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7eed000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\232b\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1171776, ...}) = 0
mmap2(NULL, 1177860, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dcd000
mmap2(0xb7ee7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11a) = 0xb7ee7000
mmap2(0xb7eea000, 10500, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eea000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dcc000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dcc6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7ee7000, 4096, PROT_READ)   = 0
munmap(0xb7eed000, 135213)              = 0
mmap2(NULL, 2002944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7be3000
exit_group(0)                           = ?
Process 10194 detached

> $ rpm -q glibc
> glibc-2.5-alt3

ditto, i586

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] q: glibc malloc s*cks?

[sr]

On Tue, Jan 16, 2007 at 12:37:28AM +0200, Michael Shigorin wrote:
> Date: Tue, 16 Jan 2007 00:37:28 +0200
> From: Michael Shigorin <mike@osdn.org.ua>
> To: ALT Devel discussion list <devel@lists.altlinux.org>
> Mail-Followup-To: ALT Devel discussion list <devel@lists.altlinux.org>
> Subject: Re: [devel] q: glibc malloc s*cks?
> 
> On Mon, Jan 15, 2007 at 11:33:03PM +0200, sr@altlinux.ru wrote:
> > > Скажите sr@, что glibc malloc уже давно использует mmap.
> > > См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html
> > Агащазблин.
> 
> Скажем так -- "умеет использовать mmap",

Не так, "не умеет использовать mmap", потому что mmap()/mremap()/munmap()
не может использоваться в прямую для malloc()/realloc()/free(), это
сразу дыры между vm_area_struct, т.е. фрагментацию на уровне юзерспэйса они
заменяют фрагментацией в ядре, хотя и в юзерспэйсе фрагментация не отменяется.
А там это таки так для больших кусков памяти. Собственно, этот, простите,
аллокатор ничем не отличается от такого же с dietlibc. Но почему он такой
в diet понятно, почему он такой же в glibc мне не понятно.

Re: [devel] q: glibc malloc s*cks?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

On Mon, Jan 15, 2007 at 11:33:03PM +0200, sr@altlinux.ru wrote:
> On Mon, Jan 15, 2007 at 05:13:42PM +0300, Dmitry V. Levin wrote:
> > Скажите sr@, что glibc malloc уже давно использует mmap.
> > См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html
> 
> Агащазблин.

Сергей, спорить со мной на моём минном поле - это довольно рискованное
мероприятие, можно одним неудачным словом подорвать свою репутацию.

$ cat malloc.c 
#include <stdlib.h>
int main(int ac, const char const **av)
{
	if (ac != 2) return 1;
	return !malloc(atoi(av[1]));
}


$ uname -m
i686
$ rpmquery glibc
glibc-2.5-alt3
$ gcc -O2 -Wall -Werror malloc.c -o malloc
$ strace -qce trace=brk,mmap2 ./malloc 1        
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
   nan    0.000000           0         3           brk
   nan    0.000000           0         6           mmap2
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                     9           total
$ strace -qce trace=brk,mmap2 ./malloc $((1024*1024))
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
   nan    0.000000           0         1           brk
   nan    0.000000           0         7           mmap2
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                     8           total


$ uname -m
x86_64
$ rpmquery glibc
glibc-2.5-alt3
$ gcc -O2 -Wall -Werror malloc.c -o malloc
$ strace -qce trace=brk,mmap ./malloc 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
   nan    0.000000           0         7           mmap
   nan    0.000000           0         3           brk
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                    10           total
$ strace -qce trace=brk,mmap ./malloc $((1024*1024))
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
   nan    0.000000           0         8           mmap
   nan    0.000000           0         1           brk
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                     9           total

$ strings /lib*/ld-2.5.so |fgrep MALLOC_MMAP
MALLOC_MMAP_MAX_
MALLOC_MMAP_THRESHOLD_

$ sed -n '/Update in 2006/,/\*\//p' glibc/malloc/malloc.c |wc -l
50

Сергей, будьте добры, прочтите эти несколько строк комментариев, после
чего, если хотите, можно вернуться к теме реализации malloc в glibc.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] q: glibc malloc s*cks?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Tue, Jan 16, 2007 at 01:18:00AM +0200, sr@altlinux.ru wrote:
> On Tue, Jan 16, 2007 at 12:37:28AM +0200, Michael Shigorin wrote:
> > On Mon, Jan 15, 2007 at 11:33:03PM +0200, sr@altlinux.ru wrote:
> > > > Скажите sr@, что glibc malloc уже давно использует mmap.
> > > > См. тж. http://sourceware.org/ml/libc-alpha/2006-11/msg00061.html
> > > Агащазблин.
> > 
> > Скажем так -- "умеет использовать mmap",
> 
> Не так, "не умеет использовать mmap", потому что mmap()/mremap()/munmap()
> не может использоваться в прямую для malloc()/realloc()/free(), это
> сразу дыры между vm_area_struct, т.е. фрагментацию на уровне юзерспэйса они
> заменяют фрагментацией в ядре, хотя и в юзерспэйсе фрагментация не отменяется.
> А там это таки так для больших кусков памяти.

Это openbsd malloc целиком построен на mmap.
А glibc malloc имени Wolfram Gloger/Doug Lea по прежнему использует brk
для размещения объектов малого размера.

Так в чём вопрос был?  Как минимизировать фрагментацию памяти
долгоживущего приложения, у которого средний размер размещаемого объёкта
около 24 байт?  Полагаю, что эффект от использования специализированного
allocator'а будет больше чем от замены универсального malloc'а.  Другое
дело что внедрить такой allocator в чужой софт немалого размера может
оказаться даже сложнее чем поменять malloc.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] q: glibc malloc s*cks?

[Michael Shigorin]

On Tue, Jan 16, 2007 at 04:26:32AM +0300, Dmitry V. Levin wrote:
> Так в чём вопрос был?  Как минимизировать фрагментацию памяти
> долгоживущего приложения, у которого средний размер
> размещаемого объёкта около 24 байт?  Полагаю, что эффект от
> использования специализированного allocator'а будет больше чем
> от замены универсального malloc'а.  Другое дело что внедрить
> такой allocator в чужой софт немалого размера может оказаться
> даже сложнее чем поменять malloc.

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

По ходу разбирательства он плавно перетёк в "надо бы проверить,
как это на текущем сизифе" -- который у меня на системах с 512+M
памяти, где гораздо менее критично (память наращивалась или
подбиралась не в последнюю очередь из-за mozilla-like, btw...).

2 sinister: можешь попробовать посмотреть, что получается
с glibc-2.5?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] [JT] glibc malloc s*cks?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Tue, Jan 16, 2007 at 04:26:32AM +0300, Dmitry V. Levin wrote:

DVL> Так в чём вопрос был?  Как минимизировать фрагментацию памяти
DVL> долгоживущего приложения, у которого средний размер размещаемого объёкта
DVL> около 24 байт?  Полагаю, что эффект от использования специализированного
DVL> allocator'а будет больше чем от замены универсального malloc'а.  Другое
DVL> дело что внедрить такой allocator в чужой софт немалого размера может
DVL> оказаться даже сложнее чем поменять malloc.

/me представил себе что начнется, если оторвать от glibc mеmory allocation
в отдельную либу... В

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<Vitls> *** Опечатка дня: [root@mw:~]# apt-get upadet ***

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]