Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Feb 2014 13:21:22 +0100
From:      Andre Albsmeier <andre@albsmeier.net>
To:        David Xu <davidxu@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Erich Dollansky <erichsfreebsdlist@alogt.com>, Andre Albsmeier <mail@ma17.ata.myota.org>
Subject:   Re: pthread programming eats up resources (My or FreeBSD's fault?)
Message-ID:  <20140221122122.GA2031@schlappy>
In-Reply-To: <5306E70D.70402@freebsd.org>
References:  <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> <5306DCC8.3080001@freebsd.org> <20140221131517.66d5b82c@X220.alogt.com> <5306E70D.70402@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21-Feb-2014 at 13:41:33 +0800, David Xu wrote:
> On 2014/02/21 13:15, Erich Dollansky wrote:
> > Hi,
> >
> > On Fri, 21 Feb 2014 12:57:44 +0800
> > David Xu <davidxu@freebsd.org> wrote:
> >
> >> On 2014/02/21 12:44, Erich Dollansky wrote:
> >>> On Thu, 20 Feb 2014 16:06:30 +0800
> >>> David Xu <davidxu@freebsd.org> wrote:
> >>>
> >>>> On 2014/02/20 14:06, Erich Dollansky wrote:
> >>>>
> >>>> I have found the bug, it is in rtld, where malloc_aligned() is
> >>>> misfunctioning, memory can be corrupted by the function.
> >>>>
> >>>> libthr calls _rtld_allocate_tls to allocate tls control block,
> >>>> the function is in rtld, its uses malloc_aligned() which is not
> >>>> working correctly.
> >>>>
> >>> I installed the patch. It is now much, much better but after hours,
> >>> something still seems wrong. Size went above 200MB after 40min of
> >>> CPU time. The number of threads is now above 1200. The machine also
> >>> has 3 zombies. The machine was restarted some 4h ago.
> >>>
> >>
> >> Default thread stack size on 32-bit machine is 1M, if you have
> >> 1024 threads, the size can be larger than 1G. I checked
> >> maxinum threads kernel allowed is max_threads_per_proc
> >> which is 1500 default. So what you have seen might be normal.
> >> I don't know what is zombie, is it a zombie process?
> >> thread library does not create process.
> >
> > I know, the zombies do not fit the scenario. Irritating is that some
> > threads stay over. Is it a side effect of the scheduler? I do my normal
> > work with the machine. The load should not block this process for long
> > as I do nothing which requires 100% for all the time.
> >
> 
> I am running your code while playing flash video, and many threads are
> accumulated, sometimes I saw a peak number at 800 or more, I think
> it is normal, because the machine is loaded, after usleep returns,
> other newly created threads may still not have chance to run, and
> your next loop creates bunch of threads again, it could be very
> easily to exceed 1000 threads.

I would like to recall that my usleep programme was just a first
shot to demonstrate the problem here on my idle machine. For real
work loads the other one (pth2) might be better as this one waits
for all threads to terminate before firing up new ones...

	-Andre

> 
> > Should I add some code to wait until the counter is zero again and see
> > what is happening then?
> >
> 
> Yes, I think so. But thread stacks will be cached by libthr, and never
> return to free space. so even if there is only one thread, you may
> see a very large size in top.
> 
> > Erich
> >
> 

-- 
Micro$oft: Which virus will you get today?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140221122122.GA2031>