From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108540 invoked by alias); 24 Jun 2019 20:13:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 108447 invoked by uid 89); 24 Jun 2019 20:13:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=gomp_task, H*i:sk:6a134c3, H*f:sk:e2a9f7c, H*f:sk:6a134c3 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Jun 2019 20:13:41 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5119E30821F4; Mon, 24 Jun 2019 20:13:39 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DA414608BA; Mon, 24 Jun 2019 20:13:38 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x5OKDalR001904; Mon, 24 Jun 2019 22:13:36 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x5OKDXc3001903; Mon, 24 Jun 2019 22:13:33 +0200 Date: Mon, 24 Jun 2019 20:13:00 -0000 From: Jakub Jelinek To: =?utf-8?B?6rmA6rec656Y?= Cc: gcc@gcc.gnu.org Subject: Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime Message-ID: <20190624201333.GN815@tucnak> Reply-To: Jakub Jelinek References: <6a134c304322d74212af4cb92605853@cweb007.nm.nfra.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6a134c304322d74212af4cb92605853@cweb007.nm.nfra.io> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00291.txt.bz2 On Tue, Jun 25, 2019 at 04:55:17AM +0900, 김규래 wrote: > I'm not very familiar with the gomp plugin system. > However, looking at 'GOMP_PLUGIN_target_task_completion' seem like tasks have to go in and out of the runtime. > In that case, is it right that the tasks have to know from which queue they came from? > I think I'll have to add the id of the corresponding queue of each task in the gomp_task structure. While libgomp has a plugin system, the only supported plugins are those in the tree, i.e. libgomp/plugin/plugin-{hsa,nvptx}.c and liboffloadmic/plugin/* nvptx plugin doesn't have async support ATM, so it is just hsa and xeonphi offloading that can call it when an asynchronous target region execution is over. No matter in which task queue the task is, gomp_target_task_completion needs to ensure that if something already waits on it (taskwait, taskgroup end, barrier, dependency wait), that it is awaken. And, like for other parts of task.c, there needs to be a design what lock is used to protect any code that needs to be guarded. The current code as you know uses team->task_lock as a big lock, I think with the separate workqueues + work stealing you need per implicit task lock + the per team (team->task_lock), design the locking such that there is no ABBA deadlock possibility and that you use the team task lock only when really necessary (not sure, but perhaps one example where I really don't see much way to avoid the per team lock are task dependencies, the hash table for that etc.). Jakub