On Saturday 16 May 2009 17:05:24 Mikolaj Golub wrote:
> On Fri, 15 May 2009 13:48:51 +0200 Marius Nünnerich wrote:
>
>  MN> On Tue, May 12, 2009 at 08:27, Mikolaj Golub <to.my.troc...@gmail.com> 
wrote:
>  >> Hi,
>  >>
>  >> The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386,
>  >> amd64):
>  >>
>  >> #include <omp.h>
>  >> #include <unistd.h>
>  >>
>  >> int n = 4, m = 2;
>  >>
>  >> int main () {
>  >>        for (;;) {
>  >>                int i;
>  >>
>  >>                //sleep(2);
>  >> #pragma omp parallel for num_threads(m)
>  >>                for(i = 0; i < 1; i++) {}
>  >>
>  >>                //sleep(2);
>  >> #pragma omp parallel for num_threads(n)
>  >>                for(i = 0; i < 1; i++) {}
>  >>
>  >>        }
>  >>
>  >>        return 0;
>  >> }
>  >>
>  >> During the run the program's virtual memory usage constantly grows. The
>  >> growth is observed only when n != m. When running the program with
>  >> uncommented sleep() and observing the number of threads with 'top -H' I
>  >> see in turn 2 or 4 threads. So it looks like memory leak when thread is
>  >> removed. Should I fill PR?
>
> It looks like I have found the leak. The problem is in libgomp/team.c.
> gomp_thread_start() does sem_init() but sem_destroy() is never called. This
> patch solves the problem for me:
>
> --- contrib/gcclibs/libgomp/team.c.orig 2009-05-16 17:32:57.000000000 +0300
> +++ contrib/gcclibs/libgomp/team.c      2009-05-16 19:16:37.000000000 +0300
> @@ -164,9 +164,12 @@ new_team (unsigned nthreads, struct gomp
>  static void
>  free_team (struct gomp_team *team)
>  {
> +  int i;
>    free (team->work_shares);
>    gomp_mutex_destroy (&team->work_share_lock);
>    gomp_barrier_destroy (&team->barrier);
> +  for(i = 1; i < team->nthreads; i++)
> +    gomp_sem_destroy (team->ordered_release[i]);
>    gomp_sem_destroy (&team->master_release);
>    free (team);
>  }
>
> I am going to fill PR to gcc mainstream, but should I also register this in
> FreeBSD bugtrack as gcc is part of the base?
>
> BTW, the problem is not observed under Linux. I have not looked in Linux
> code but it looks like sem_init() implementation for Linux does not do
> memory allocation. The memory for the test program below grows under
> FreeBSD and does not under Linux.

Note that libgomp uses it's own implementation of POSIX semaphores (using 
phtread mutexes) instead of FreeBSD's sem(4). If the program below is run 
against FreeBSD's implementation, it quickly stops growing because there is a 
limit on the number of allocated semaphores.

It would be interesting to see if there are any differences performance wise 
between the two. If the native version is faster, it might be another reason 
to include sem(4) in the GENERIC kernel...

>
> #include <semaphore.h>
>
> int
> main(int argc, char *argv[]) {
>
>         sem_t sem;
>
>         for(;;) { sem_init(&sem, 0, 0);}
>
>         return 0;
> }

--
Pieter de Goeje


_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to