Date: Thu, 29 Mar 2007 16:33:52 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Ivan Voras <ivoras@fer.hr> Cc: freebsd-current@freebsd.org Subject: Re: malloc(3) (hopefully) set for 7.0 Message-ID: <20070329203352.GA73837@xor.obsecurity.org> In-Reply-To: <eugubt$gf9$1@sea.gmane.org> References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> <460AE766.6050409@frebsd.org> <eugubt$gf9$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 07:51:56PM +0200, Ivan Voras wrote: > Jason Evans wrote: >=20 > > I have developed some novel algorithms for essentially eliminating > > thread contention on SMP systems, but it is too late in the development > > cycle to introduce such changes (not to mention that I lack the hardware > > to evaluate the algorithms). Thanks again for your patience and > > support. Please let me know if I can be of help in diagnosing suspected > > malloc issues. >=20 > First, thanks :) >=20 > Second, as a user, I'd really like if you could manage to implement > those ideas before 7.0, and here's why: >=20 > - The standard for new servers here is 4 cores (in various socket > arrangements), and we're not at all high-tech. This is likely to go up. > - If you include hyperthreading, even all *desktops* are SMPs! In short, > even including desktops, I haven't installed a UP kernel in about a year. > - It's too long to wait for 8.0 for something as important as this. As > far as I can see, 7.0 will be one of the "break as many things as you > need" releases (in the "good" sense, of course), so why not go for it. > Judging from past releases, "even" releases (4.x, 6.x) have been the > ones people trusted the most, so if you do get a glitch in 7.0 it won't > be as bad :) (of course, you can fix it in 7.1 :) ) >=20 > Maybe you could borrow the 8CPU machine used for MySQL / filedesc tuning > jeffr and others have been using (of course, once they've finished...)? I will be happy to (continue to) work with Jason on testing his changes, but there appears to be no urgent need for this: the mysql benchmark specifically shows that jemalloc scales well on 8 CPUs. In fact, the scalability problem seen on Linux turned out to be precisely because of poor scaling of glibc malloc http://ozlabs.org/~anton/linux/sysbench/ Kris --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGDCKwWry0BWjoQKURAnDJAJ9PIV8V3Bx0C1/Ce7sUU1UGvSvEpQCfYOoq 2GACt/d46rO1BurjbozXnOA= =KXtm -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070329203352.GA73837>