Date: Wed, 27 Mar 2013 11:33:46 -0700 (PDT) From: Unga <unga888@yahoo.com> To: Ian Lepore <ian@FreeBSD.org> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@FreeBSD.org> Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] Message-ID: <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> In-Reply-To: <1364393170.36972.49.camel@revolution.hippie.lan> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A----- Original Message -----=0A=0A> From: Ian Lepore <ian@FreeBSD.org= >=0A> To: Unga <unga888@yahoo.com>=0A> Cc: "freebsd-stable@freebsd.org" <fr= eebsd-stable@FreeBSD.org>=0A> Sent: Wednesday, March 27, 2013 2:06 PM=0A> S= ubject: Re: FreeBSD 9.1 excessive memory allocations=0A> =0A> On Tue, 2013-= 03-26 at 11:35 -0700, Unga wrote:=0A>> Hi all=0A>> =0A>> =0A>> I have a h= eavily threaded C application, developed on an Intel Core i5 =0A> laptop (2= cores) running FreeBSD 8.1-RELEASE.=0A>> =0A>> When this application comp= ile and run on another Intel Core i7 laptop (4 =0A> cores) running FreeBSD = 9.1-RELEASE, this application immediately starts grabbing =0A> memory by ov= er 100MB per second and soon exit with not enough RAM.=0A>> =0A>> =0A>> Bo= th laptops having 4GB RAM.=0A>> =0A>> All malloc and free are mutex locked= .=0A>> =0A>> Very rarely this problem happens on the i5 (2 cores) laptop t= oo, but on the =0A> i7 laptop, it happens every time.=0A>> =0A>> Appreciat= e any feedback to identify and fix this issue.=0A>> =0A>> Best regards=0A>= > Unga=0A>> =0A> =0A> Too many moving parts, you need to partition the pro= blem.=A0 Is it the=0A> change in OS (and especially libraries) that causes = the problem, or the=0A> change in the number of cores (more concurrent thre= ads) is exposing some=0A> sort of application-side race condition?=A0 Given= the fact that it does=0A> occur on 2 cores + freebsd 8.1, even if more rar= ely, it's almost surely=0A> an application problem.=A0 =0A> =0A> Perhaps yo= u could use a tool such as valgrind to help track down the=0A> runaway allo= cations?=0A> =0A> Another way to expose thread race problems is to force mo= re thread=0A> context switches.=A0 A blunt tool for doing so is to set hz= =3D5000 or even=0A> higher in /boot/loader.conf.=A0 I've never done that on= a desktop or=0A> laptop system, only on embedded systems, but it should st= ill work okay.=0A> If changing the application code is easier, you can get = a similar effect=0A> by creating a thread whose only job is to preempt othe= r threads, by=0A> using rtprio_thread() to set it to real time priority, th= en just have it=0A> sleep for short random intervals (microseconds), all it= does is wakes up=0A> and goes right back to sleep.=0A> =0A> Also, FYI, the= re's no need to use a mutex in your application to protect=0A> allocations.= =A0 The memory allocator in libc is thread-safe, and in fact=0A> is particu= larly designed for efficient multi-threaded allocation.=0A> =0A> -- Ian=0A>= =0A=0ADear Tony, Alexander, Jan, Ian and Jeremy=0A=0AThank you very much fo= r your very valuable comments.=0A=0AProblem seems to be solved. But require= more testing.=0A=0A1. Fixed an application-level crucial bug. This is near= ly a 7000 lines C app. It was really hard to see as the application is desi= gned with 8 dedicated threads.=0A=0A2. At run-time, this application shoots= up to about 400 dynamic threads on the i7 machine, whereas on the i5 machi= ne, it only shoots up 57 dynamic threads. It was bit scaring, therefore, ma= de a hard limit on total number of threads to 64.=0A=0ARegarding mutex lock= s on allocations, as per the malloc(3), it says small and medium size alloc= ations are done from per thread caches, therefore, thread-safe. My allocati= ons are large in nature, about 5-7MB.=0A=0ABest regards=0AUnga
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1364409226.37379.YahooMailNeo>