From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 12:21:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A69C8DA; Fri, 21 Feb 2014 12:21:48 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id ADB96169F; Fri, 21 Feb 2014 12:21:46 +0000 (UTC) Received: from mobile.client (177.189.166.190.f.sta.codetel.net.do [190.166.189.177] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1LCLVAV079789; Fri, 21 Feb 2014 13:21:34 +0100 (CET) (envelope-from andre@albsmeier.net) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1LCLM5c002053; Fri, 21 Feb 2014 13:21:23 +0100 (CET) (envelope-from andre@schlappy.albsmeier.net) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1LCLMTA002052; Fri, 21 Feb 2014 13:21:22 +0100 (CET) (envelope-from andre@schlappy.albsmeier.net) Date: Fri, 21 Feb 2014 13:21:22 +0100 From: Andre Albsmeier To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140221122122.GA2031@schlappy> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5306E70D.70402@freebsd.org> X-Echelon: Hackers, SDI, Delta, InfoSec, S/Key X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 21 Feb 2014 14:04:06 +0000 Cc: freebsd-hackers@freebsd.org, Erich Dollansky , Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 12:21:48 -0000 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 wrote: > > > >> On 2014/02/21 12:44, Erich Dollansky wrote: > >>> On Thu, 20 Feb 2014 16:06:30 +0800 > >>> David Xu 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?