From patchwork Thu Mar 26 16:46:19 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 1262154 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48p9qh6Rdwz9sRf for ; Fri, 27 Mar 2020 03:46:39 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 423F63861C58; Thu, 26 Mar 2020 16:46:37 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 4C8FC385E011 for ; Thu, 26 Mar 2020 16:46:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4C8FC385E011 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Thomas_Schwinge@mentor.com IronPort-SDR: XNTTIRu1tXzq34d1ZeNjBP1Uf4WZ4eM9kCbZtggMEz9FmeaJQBppLqjEEv8sYoUqigKldW5mzh TBSk3/S7nYfqaTu+azJLsfGMNkPGAjqg07bQZ3Z7ULZrk3bhmE5CvdXNoETrvoRcjY4pvMQ9Zq QAmY8r4MrBTvL+HRWTarVLSpm/zyf2WQxbrnMXCU/wZUG0hNbsBYTrgA8jpsB1eTV0LyKMqbat HaV7XevhLNfwvEaK6wldllRn6hIDGo5aCAcpmnycnGxh3gt7sDZWM7R/hVCQT9VNDldz/w8svv NkE= X-IronPort-AV: E=Sophos; i="5.72,309,1580803200"; d="scan'208,223"; a="47147202" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 26 Mar 2020 08:46:33 -0800 IronPort-SDR: 7ddrte3r5rMrVOwTPKwgPE4eTdPa4vuMFJfxK1MxnjLcWvpiL1iIObpy7a+tc/oTeoMxRfi5TD 2fw3ayduDHXurMRBe0cZJr45CdmTPG5OmKCz1z/GnCWqmPtWoJUMO6uHG+55NbG71oxyYzuGfc ox9AVTYRAeDhfrrA2fsFj/6BCA4ZPSo8d+sLGvax0FOF5SXeQVfXhoeHFtCid7KviCV5ArBrga hmwHZAK5QQ1pGTk4Ksqm0yboj6syeyZrnInMh5+3r1JJhTe4HqPsdDsnhYYFuXvB/XgnKdP1Lh F9I= From: Thomas Schwinge To: , Frederik Harwath Subject: [og9] Really fix og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof" In-Reply-To: References: <87k28acit3.fsf@hertz.schwinge.homeip.net> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Thu, 26 Mar 2020 17:46:19 +0100 Message-ID: MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) X-Spam-Status: No, score=-30.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LOTSOFHASH, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kwok Cheung Yeung Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Hi! On 2020-03-25T18:09:25+0100, I wrote: > On 2018-02-22T12:23:25+0100, Tom de Vries wrote: >> when using cuda 9 nvprof with an openacc executable, the executable hangs. > What Frederik has discovered today in the hard way... is that the og9 > version of this patch did get its code altered in a way so that it no > longer resolves the problem it's meant to resolve -- the hang was back. > On Git-mirror-based openacc-gcc-9-branch that's: > > commit 84af3c5a2fbb5023057e2ca319b0c22f5f7d4795 > Author: Julian Brown > AuthorDate: Tue Feb 26 16:00:54 2019 -0800 > Commit: Kwok Cheung Yeung > CommitDate: Fri May 31 13:40:07 2019 -0700 > > Fix hang when running oacc exec with CUDA 9.0 nvprof > > 2018-09-20 Tom de Vries > Cesar Philippidis > > libgomp/ > [...] > > ..., which got cherry-picked (automated, without any review) into current > devel/omp/gcc-9 in commit f752d880a5abc591a25ad22fb892363f6520bcf1. OK, I had confused myself here. I wrongly blamed that commit to be responsible for the hang being back, when in fact it's only the later og9 "OpenACC Profiling Interface (incomplete)" backport from trunk that introduced the problem. On Git-mirror-based openacc-gcc-9-branch that's: commit 1246da4f164bcf2ec4430b89686a38c47e55b5f9 Author: tschwinge AuthorDate: Fri May 17 19:13:36 2019 +0000 Commit: Kwok Cheung Yeung CommitDate: Fri Jul 26 14:32:02 2019 -0700 OpenACC Profiling Interface (incomplete) libgomp/ [...] ..., which got cherry-picked (automated, without any review) into current devel/omp/gcc-9 in commit 9342531a7fc9f6e368e37bbd4ea9f4d01f43514e. The confusing thing was that the og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof" commit appears *before* the og9 "OpenACC Profiling Interface (incomplete)" backport that it relates to. And, in addition to that, I pushed the wrong (incomplete) version of my fix. > Of course, it would've helped tremendously had the original og7 commit > included a test case... :'-/ (... by simply reproducing the nested calls > that CUDA 9 nvprof seems to be doing.) > > Still without a test case, for now I have pushed the attached patch to > devel/omp/gcc-9 in commit 9ae129017c7fc1fa638d6beedd3802b515ca692b 'Fix > og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof"'. ..., and now the attached patch to devel/omp/gcc-9 in commit 775f1686a3df68bd20370f1fabc6273883e2c5d2 'Really fix og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof"'. Grüße Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter From 775f1686a3df68bd20370f1fabc6273883e2c5d2 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 26 Mar 2020 17:34:01 +0100 Subject: [PATCH] Really fix og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof" In my yesterday's commit 9ae129017c7fc1fa638d6beedd3802b515ca692b 'Fix og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof"', I wrongly blamed the og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof" to be responsible for the hang being back, when in fact it's only the later og9 "OpenACC Profiling Interface (incomplete)" backport from trunk that introduced the problem. The confusing thing was that the og9 "Fix hang when running oacc exec with CUDA 9.0 nvprof" commit appears *before* the og9 "OpenACC Profiling Interface (incomplete)" backport that it relates to. And, in addition to that, I pushed the wrong (incomplete) version of my fix. libgomp/ * oacc-init.c (acc_init_1): Move other 'acc_init_state' logic to where it belongs. --- libgomp/ChangeLog.omp | 5 +++++ libgomp/oacc-init.c | 12 ++++++++---- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp index 75c45917998..922e00fbff5 100644 --- a/libgomp/ChangeLog.omp +++ b/libgomp/ChangeLog.omp @@ -1,3 +1,8 @@ +2020-03-26 Thomas Schwinge + + * oacc-init.c (acc_init_1): Move other 'acc_init_state' logic to + where it belongs. + 2020-03-25 Thomas Schwinge * oacc-init.c (acc_init_1): Move 'acc_init_state' logic to where diff --git a/libgomp/oacc-init.c b/libgomp/oacc-init.c index 765fa2f3b95..40c14fa9bf2 100644 --- a/libgomp/oacc-init.c +++ b/libgomp/oacc-init.c @@ -317,10 +317,6 @@ acc_init_1 (acc_device_t d, acc_construct_t parent_construct, int implicit) gomp_init_device (acc_dev); gomp_mutex_unlock (&acc_dev->lock); - gomp_mutex_lock (&acc_init_state_lock); - acc_init_state = initialized; - gomp_mutex_unlock (&acc_init_state_lock); - if (profiling_p) { prof_info.event_type = acc_ev_device_init_end; @@ -329,6 +325,14 @@ acc_init_1 (acc_device_t d, acc_construct_t parent_construct, int implicit) &api_info); } + /* We're setting 'initialized' *after* 'goacc_profiling_dispatch', so that a + nested 'acc_get_device_type' called from a profiling callback still sees + 'initializing', so that we don't deadlock when it then again tries to lock + 'goacc_prof_lock'. See also the discussion in 'acc_get_device_type'. */ + gomp_mutex_lock (&acc_init_state_lock); + acc_init_state = initialized; + gomp_mutex_unlock (&acc_init_state_lock); + return base_dev; } -- 2.17.1