From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D3394198005 for ; Wed, 27 Feb 2013 20:26:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 17701E08D1; Wed, 27 Feb 2013 20:26:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2EB9FE07FC for ; Wed, 27 Feb 2013 20:26:42 +0000 (UTC) Received: from sf (unknown [178.121.252.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id 64B7633DE7D; Wed, 27 Feb 2013 20:26:40 +0000 (UTC) Date: Wed, 27 Feb 2013 23:26:02 +0300 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org Cc: ryao@gentoo.org Subject: Re: [gentoo-dev] Evaluating a new malloc() Message-ID: <20130227232602.3de39b88@sf> In-Reply-To: <512CB9B8.9060308@gentoo.org> References: <512CB9B8.9060308@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.12; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/WxV/RlseOqKj=o6cnCY5B.s"; protocol="application/pgp-signature" X-Archives-Salt: 58e5ca22-8d29-4300-89d7-5254b0563f96 X-Archives-Hash: 68216e196a11564555755d871fa9ada0 --Sig_/WxV/RlseOqKj=o6cnCY5B.s Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 26 Feb 2013 08:33:44 -0500 Richard Yao wrote: > The Blender project found some fairly remarkable discrepancies between > what their software actually used and what glibc's ptmalloc allocated: >=20 > http://www.sintel.org/development/memory-jemalloc/ >=20 > Results such as these led Blender and others (e.g. Chrome/Chromium, > Firefox, Thunderbird) to bundle private versions of jemalloc. Thre real disease is Windows support for all the mentioned apps. glibc is not that bad. I suspect export MALLOC_CHECK_=3D0 and CFLAGS=3D-fno-stack-protector would solve all those bookkeeping "issues" glibc dumps on you by default. malloc() (likely free()) performance dependency for an app means writing custom allocators. IMHO it's a per-app problem, not system-wide one. Do you have degradation example for your use cases? (a sample program for real workload) Fixing known deficiencies is always simpler than switching known-to-work base. > This bundling situation violates our policy against bundled libraries. The > maintainers could just patch their software to link to libjemalloc. > However, it might make more sense to evaluate jemalloc as a > distribution-wide replacement for glibc's ptmalloc. It would not solve bundling problem, would it? > Unless a significant issue is found in jemalloc itself, I do not see any > reason to continue using glibc's ptmalloc over jemalloc. How about "that core piece of libc works fine"? --=20 Sergei --Sig_/WxV/RlseOqKj=o6cnCY5B.s Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEua98ACgkQcaHudmEf86oRBQCfTFkfEzhYk3ASeufjveAe9Xw8 KPgAnA8yJ2aNLLW8lWN7DZ41+i10gzls =rDT1 -----END PGP SIGNATURE----- --Sig_/WxV/RlseOqKj=o6cnCY5B.s--