From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27993 invoked by alias); 2 Feb 2011 20:28:07 -0000 Received: (qmail 27984 invoked by uid 22791); 2 Feb 2011 20:28:06 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Feb 2011 20:28:02 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 284B416009; Wed, 2 Feb 2011 12:27:59 -0800 (PST) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id 19314CD9FE; Wed, 2 Feb 2011 12:27:59 -0800 (PST) Message-ID: <4D49BE4E.9000009@vmware.com> Date: Wed, 02 Feb 2011 20:28:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.24 (X11/20101201) MIME-Version: 1.0 To: Markus Alber CC: "gdb@sourceware.org" Subject: Re: performance of multithreading gets gradually worse under gdb References: <8b62d2819c94a232987155aa99e01983@hyperion-imrt.org> In-Reply-To: <8b62d2819c94a232987155aa99e01983@hyperion-imrt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00011.txt.bz2 Markus Alber wrote: > Hello, > > I have experienced the following problem: > > I'm debugging a number-crunching application which spawns a lot (36) > little > worker threads per iteration. The system does typically OoM 200 > iterations. > Although each of them should take about the same amount of time, the > performance > gets worse with every iteration and becomes excruciatingly slow. > > A system monitor reveals that gdb allocates more memory with every > iteration, > i.e. with every 36 threads started and finished. The CPU load of GDB > goes up, too. > The CPU usage of the application goes down. Compared to the solo > performance, it > gets slower by a factor 20 and more, if run long enough. > > The application behaves perfectly when run by itself. The > multi-threaded part is not > debugging compiled when this behaviour occurs. > > The distribution is SuSE 11.3 / gdb 7.1. > > Is there anything I can change about this behaviour, any options of gdb > that need to > be set in these circumstances? Interesting. By how much does gdb's memory allocation increase? In total or, if possible, per iteration? This might give is a clue as to where to look. Do you think you could write a simple sample program that allocates threads in a manner similar to your application? Thanks,