From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 15 Jan 2007 15:59:34 +0200 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20070115135934.GL30255@osdn.org.ua> Mail-Followup-To: devel@lists.altlinux.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i Subject: [devel] q: glibc malloc s*cks? X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 13:59:45 -0000 Archived-At: List-Archive: List-Post: Здравствуйте. Тут нашлось неожиданное применение недавно пробегавшему 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 ------ Linux.Kiev http://www.linux.kiev.ua/