From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87297 invoked by alias); 19 May 2019 18:55:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 87289 invoked by uid 89); 19 May 2019 18:55:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=nor, unusual, HX-Languages-Length:2494 X-HELO: gateway20.websitewelcome.com Received: from gateway20.websitewelcome.com (HELO gateway20.websitewelcome.com) (192.185.50.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 May 2019 18:55:07 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway20.websitewelcome.com (Postfix) with ESMTP id D611D401B6B30 for ; Sun, 19 May 2019 13:55:05 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id SQxdh0IRR2qH7SQxdhFwSW; Sun, 19 May 2019 13:55:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TGuE3AZFZuHqdN9Nor+yGBkG3IItnI6B895dRgejMCw=; b=rlbULVJFgWXPv5dx7wsBkvJ6Ob dzuBpD+xb+hsqBw5px62ATfUsPMmM+WnvvJr152chnQacDz85vq02W2xJ+Tq38bERFMBBzzY7PZ5x Wi3BwyCLX8O1llBgeukRR3an3; Received: from 71-218-69-43.hlrn.qwest.net ([71.218.69.43]:47972 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hSQxd-002JCu-Lr; Sun, 19 May 2019 13:55:05 -0500 From: Tom Tromey To: Philippe Waroquiers Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads References: <20190518210010.27697-1-tom@tromey.com> <1558274338.1454.13.camel@skynet.be> Date: Sun, 19 May 2019 18:55:00 -0000 In-Reply-To: <1558274338.1454.13.camel@skynet.be> (Philippe Waroquiers's message of "Sun, 19 May 2019 15:58:58 +0200") Message-ID: <87a7figtpz.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-05/txt/msg00458.txt.bz2 >>>>> "Philippe" == Philippe Waroquiers writes: Philippe> That looks like a nice startup speed improvement, will be much appreciated Philippe> when debugging big executables at work :). Philippe> I however do not observe much parallel CPU being used. Philippe> What type of operations will be mostly helped by parallel threads ? With this series, only demangling of minimal symbols is parallelized. This does not dominate startup except in unusual situations, maybe a very large C++ library that has no debuginfo and is unstripped. Locally I only saw utilization of 1.5 CPUs or so -- so, not very parallel yet. The real point of this series is to flush out some of the lower-level problems with having threading in gdb, so we can use it in more places. For example, in this series, the SEGV handler stuff; but also this was the reason for the big exception handling changes. A better win, I think, would be to parallelize partial symbol reading in dwarf2read.c. This is a bit tricky... there are cross-CU references to consider, and also the bcache seems like a point of contention. I've been wondering if, instead, it would make sense to change the DWARF reader not to make partial symbols at all. Philippe> One comment about 'maint set|show enable-threads' : Philippe> what is the reason to have this as a maintenance command ? I see it as a setting for gdb developers, not gdb users. In fact, v1 didn't have this, but John wanted a way to disable threading for debugging gdb. Philippe> Also, maybe it would be better to have this setting being the Philippe> maximum nr of threads to use. In some environments (e.g. Philippe> operational environments), one might want to limit the nr of threads Philippe> used by GDB. I think that most users don't know what most programs do under the hood; nor should they need to. I suppose in some extreme situation maybe someone would want to do this, but disabling threading in this case should be good enough. Users like this should probably use gdbserver instead though. Philippe> Note also that I see GDB is starting some threads by default Philippe> when guile is configured in, and 'maint set enable-threads off' Philippe> seems to not disable this type of threading. Guile creates threads by default. In general gdb can't control the threads made by either Guile or Python, because those can be made by scripts created at runtime. Tom