Re: FreeBSD 9.1 excessive memory allocations [SOLVED]

----- Original Message -----

> From: Ian Lepore <ian@FreeBSD.org>
> To: Unga <unga888@yahoo.com>
> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@FreeBSD.org>
> Sent: Wednesday, March 27, 2013 2:06 PM
> Subject: Re: FreeBSD 9.1 excessive memory allocations
> =

> On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
>>  Hi all
>> =

>> =

>>  I have a heavily threaded C application, developed on an Intel Core i5 =

> laptop (2 cores) running FreeBSD 8.1-RELEASE.
>> =

>>  When this application compile and run on another Intel Core i7 laptop (=
4 =

> cores) running FreeBSD 9.1-RELEASE, this application immediately starts g=
rabbing =

> memory by over 100MB per second and soon exit with not enough RAM.
>> =

>> =

>>  Both laptops having 4GB RAM.
>> =

>>  All malloc and free are mutex locked.
>> =

>>  Very rarely this problem happens on the i5 (2 cores) laptop too, but on=
 the =

> i7 laptop, it happens every time.
>> =

>>  Appreciate any feedback to identify and fix this issue.
>> =

>>  Best regards
>>  Unga
>> =

> =

> Too many moving parts, you need to partition the problem.=A0 Is it the
> change in OS (and especially libraries) that causes the problem, or the
> change in the number of cores (more concurrent threads) is exposing some
> sort of application-side race condition?=A0 Given the fact that it does
> occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely
> an application problem.=A0 =

> =

> Perhaps you could use a tool such as valgrind to help track down the
> runaway allocations?
> =

> Another way to expose thread race problems is to force more thread
> context switches.=A0 A blunt tool for doing so is to set hz=3D5000 or even
> higher in /boot/loader.conf.=A0 I've never done that on a desktop or
> laptop system, only on embedded systems, but it should still work okay.
> If changing the application code is easier, you can get a similar effect
> by creating a thread whose only job is to preempt other threads, by
> using rtprio_thread() to set it to real time priority, then just have it
> sleep for short random intervals (microseconds), all it does is wakes up
> and goes right back to sleep.
> =

> Also, FYI, there's no need to use a mutex in your application to protect
> allocations.=A0 The memory allocator in libc is thread-safe, and in fact
> is particularly designed for efficient multi-threaded allocation.
> =

> -- Ian
>

Dear Tony, Alexander, Jan, Ian and Jeremy

Thank you very much for your very valuable comments.

Problem seems to be solved. But require more testing.

1. Fixed an application-level crucial bug. This is nearly a 7000 lines C ap=
p. It was really hard to see as the application is designed with 8 dedicate=
d threads.

2. At run-time, this application shoots up to about 400 dynamic threads on =
the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic thr=
eads. It was bit scaring, therefore, made a hard limit on total number of t=
hreads to 64.

Regarding mutex locks on allocations, as per the malloc(3), it says small a=
nd medium size allocations are done from per thread caches, therefore, thre=
ad-safe. My allocations are large in nature, about 5-7MB.

Best regards
Unga
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"