[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/