From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2F1FD3858D38; Mon, 23 Jan 2023 14:53:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F1FD3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674485591; bh=o8iPJrARCsa8kPRFYqPb6+fJpCjEBmc6CZCE2/dX9rg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nbt/Qm31SqjJMRM5T7hYMCJn5MEhmwceqsZqmPU0/BiPHL08wUqGt1lhated9Nqi3 AwJiNnxIpkelK/iFKPpyqvMEBfaxwAouXJd//RVCIWxMeAoJlNs3U4tLGFcjeUByqA tpUk3Uk0ZvftYk1mwzTc0GOcVHTBK/6cwe+GxUbw= From: "amonakov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/108494] Slow thread creation with nested loops in GFortran Date: Mon, 23 Jan 2023 14:53:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgomp X-Bugzilla-Version: 12.2.1 X-Bugzilla-Keywords: openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: amonakov at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108494 Alexander Monakov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- (note, the omp_get_num_procs is just the closest dynamic symbol, with libgomp1-debuginfo the full symbol table will be available, and perf output will be more sensible) We don't reuse threads from nested parallel regions. This comment in team.c seems relevant: /* We only allow the reuse of idle threads for non-nested PARALLEL regions. This appears to be implied by the semantics of threadprivate variables, but perhaps that's reading too much into things. Certainly it does prevent any locking problems, since only the initial program thread will modify gomp_threads. */=