From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id B1EDB3858D20 for ; Tue, 14 Nov 2023 17:31:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B1EDB3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B1EDB3858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=96.47.72.81 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699983104; cv=pass; b=dl3/rKeiaNZwNQ7cSp6oSKAdZV40m0GasFsA10G5Wjx83tZ5UcI3b2H9k8jrXdBG1jOvQs7bQARNtULby64oMEZMv5NrwUJHSJA6hvDA0XYnGjeT+fyoOSsOnYHoZoJ7pr4yN4jZaSy7kvFGZWDJLgNl4I+z0ilbMLMeWKP09jY= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699983104; c=relaxed/simple; bh=IdbIc8yPJ3bzDWKg4VztxKG3aRlncPr9W3SRcNxiDcQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=lDjgM6ewELORblM5NZxDwWRwvksCofXD31hax6VKuM19uRCM0yYXXl50oE1qjgthoRk71G7sAxX47N7XXc9rgzoC3U2KiwMq+M4SXcDI+vbNDOkUhHVMC8gkxJUmGNI9Yw52J4lwjBsBJAYciOk/VYPr2BLXEuVQ085hlNLkUOs= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4SVCyj62VDz4lqF; Tue, 14 Nov 2023 17:31:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SVCyj2nsZz3VlQ; Tue, 14 Nov 2023 17:31:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699983101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UxT/gBYHyIPFE/wA/yiX1DbIQNBSfYLQ4W4jjHXl/CE=; b=MeGQrpPCJBeVJQKUGFFg4JolHPqW0JoTsULm/2M0m9eOfW4KGFQrEiaUrRklhsx5DugnJY IgpZ4Ayj6h+rX+eTaLenJLpEenIXE8u/DMNoALPbQdK6N/HmJWsES7Pg8GDNyt1vZi/QaL C5VxcRofaY7nbD7ZbHMBEMf/pNV91tbM2LkcYNf83PY96BagbTqmF5pa0qdKH8bI8rGumu 4rfSw/kBTrK0Sgegi3TqrJ99P4I8yza3rF9mAeOFkgA3MIoBlhAdgLw0I6L7ke3Ydq46IW j+nwCVl5+/51AY18ed+MHF0ZyqECNy43PP4QpqYNn6uZTu3JJ+8rs8PN8am0WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699983101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UxT/gBYHyIPFE/wA/yiX1DbIQNBSfYLQ4W4jjHXl/CE=; b=NSPnyC57rDhKH8fuIVYz09t85xI0TCCv9OOfo0JO1+5DmRKdNUiQ6KrFF+wrEYgNWugMrU 8nPa6TSqYkmz/yNNl2ZCgyiA3zhUKGyXH287QV0MSPSv1qcGL37snhbsudozohAN40qacT 6Ky/s7V0xtUi3rYBF/XVZOrTnewMMvGd5jRjDoj5slb8bqOapWWbqovveh3cmoz6y6A0G1 HRyDFF69/mtqXvw24KHdDf+K4oY4Gg2Ussb/59su/T9VURXmy89ktlV1z4CwAQANBlD8dP yOdNL45NKzKUPU4daYRO9z2XHMQDaSm5SMHbRbKLgxGX9hVY3hDGWmPVjkr5aQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699983101; a=rsa-sha256; cv=none; b=c0EFsJAfyy+2Ip7hx1pdCndupMMEZaEkL4hQb1RwvoQRR36UK+lGR3NHQHZ2fN6hsBjnLp VE6mz30k3kHymCgGhI6fVCocnTLcYqqYWnTMhPsNshXo8RDsSBOemwLfxt88wPbnvmS1RK ztaS01pC46tITr6ydBH/TeJsvbGlrPWBJKimpmGu8U/pw7F4nMCeY6DfRm8AyU7K9vYVf5 9kCM3wNe1CJn9T8dBrduQxaluDmI3Jq4tQ6LGiXojnhc9+/3pwbBd/C5aSCux1pBAOvNJn ChocPqXEH8ncXpVW9m2QNCDvidaUK0qMAys618vENiNUmqKcAsuwhiohJbVNqg== Received: from [IPV6:2601:648:8384:fd00:85e6:3fb3:bdd3:e0f9] (unknown [IPv6:2601:648:8384:fd00:85e6:3fb3:bdd3:e0f9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SVCyh6g11z15nx; Tue, 14 Nov 2023 17:31:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 14 Nov 2023 09:31:39 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/18] Do more DWARF reading in the background Content-Language: en-US To: Tom de Vries , Tom Tromey , gdb-patches@sourceware.org References: <20231112-t-bg-dwarf-reading-v2-0-70fb170012ba@tromey.com> <20231112-t-bg-dwarf-reading-v2-11-70fb170012ba@tromey.com> <3c87a020-8921-4adf-8c9a-d0bd5af62b86@suse.de> <246a3715-4aeb-42f4-a977-c5ebd53e0240@FreeBSD.org> <16a9ae74-af0d-41f7-86b9-8b9b55c45b9f@suse.de> From: John Baldwin In-Reply-To: <16a9ae74-af0d-41f7-86b9-8b9b55c45b9f@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/13/23 11:39 AM, Tom de Vries wrote: > On 11/13/23 18:56, John Baldwin wrote: >> On 11/12/23 11:15 PM, Tom de Vries wrote: >>> On 11/12/23 21:25, Tom Tromey wrote: >>>> + /* How much effort should be put into each worker. */ + const size_t >>>> size_per_thread = total_size / n_worker_threads; >>> >>> I've tested the patch series on x86_64-linux, and ran into trouble in >>> one test-case: >>> ... >>> (gdb) file >>> /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-dummy-cu/dw2-dummy-cu^M >>> Reading symbols from >>> /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-dummy-cu/dw2-dummy-cu...^M >>> /data/vries/gdb/src/gdb/dwarf2/read.c:5000: internal-error: do_reading: >>> Assertion `iter != last' failed.^M >>> A problem internal to GDB has been detected,^M >>> further debugging may prove unreliable.^M >>> ----- Backtrace -----^M >>> ERROR: Couldn't load dw2-dummy-cu into GDB (GDB internal error). >>> Resyncing due to internal error. >>> (gdb) maint expand-symtab^M >>> 0x5ac476 gdb_internal_backtrace_1^M >>>           /data/vries/gdb/src/gdb/bt-utils.c:122^M >>> 0x5ac519 _Z22gdb_internal_backtracev^M >>>           /data/vries/gdb/src/gdb/bt-utils.c:168^M >>> 0xd11a89 internal_vproblem^M >>>           /data/vries/gdb/src/gdb/utils.c:396^M >>> 0xd11e58 _Z15internal_verrorPKciS0_P13__va_list_tag^M >>>           /data/vries/gdb/src/gdb/utils.c:476^M >>> 0x14ca6f0 _Z18internal_error_locPKciS0_z^M >>>           /data/vries/gdb/src/gdbsupport/errors.cc:58^M >>> 0x72b01b _ZN19cooked_index_worker10do_readingEv^M >>>           /data/vries/gdb/src/gdb/dwarf2/read.c:5000^M >>> ... >>> >>> This fixes the test-case for me: >>> ... >>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c >>> index 385160de0fd..191c2ad7f26 100644 >>> --- a/gdb/dwarf2/read.c >>> +++ b/gdb/dwarf2/read.c >>> @@ -4974,7 +4974,8 @@ cooked_index_worker::do_reading () >>>        = std::max (gdb::thread_pool::g_thread_pool->thread_count (), >>> (size_t) 1); >>> >>>      /* How much effort should be put into each worker.  */ >>> -  const size_t size_per_thread = total_size / n_worker_threads; >>> +  const size_t size_per_thread >>> +    = std::max (total_size / n_worker_threads, (size_t)1); >> >> Presumably total_size was zero in that case? > > No, it was 11. > >> Should there be a shortcut >> to bother queueing a task in that case instead perhaps?  Or alternatively >> is the issue that total_size is < n_worker_threads? > > Yes, n_worker_threads was 12. > >> If the latter, then >> a min size of 1 does seem sensible. >> > > Thanks for the review. Is it possible that you want size_per_thread to always round up? That is, if you had total_size == 23 with n_worker_threads == 12, is there a reason to prefer size_per_thread being 2 in that case vs 1? (E.g. if the threads each do "size_per_thread" items with the last one handling any remainder, then you'd probably prefer 2 so that 11 threads do 2 and the last thread does 1 rather than 11 threads doing 1 and the last thread doing 11.) Looking at the patch, I do think it's the case I described, so perhaps you want to always round up via: const size_t size_per_thread = (total_size + n_worker_threads - 1) / n_worker_threads; -- John Baldwin