From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 05:40:58 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 19DD9C90 for ; Fri, 21 Feb 2014 05:40:58 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB4F71324; Fri, 21 Feb 2014 05:40:57 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1L5etlU064374; Fri, 21 Feb 2014 05:40:56 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5306E70D.70402@freebsd.org> Date: Fri, 21 Feb 2014 13:41:33 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) 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> In-Reply-To: <20140221131517.66d5b82c@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, 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 05:40:58 -0000 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. > 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 >