From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4772D3858C52 for ; Fri, 9 Sep 2022 16:02:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4772D3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662739345; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qTsmreW0vKi/IzKt3V7mV3ZoYlvlObCIFG5IuNlyHg8=; b=JL9k2AL6yqafx2+gur8Prmqi85Xf5Clcz7XCFF/qaLv21mFn1wbNkZnZCfxVUE7Fb2yNfM 9kjGcNPVoj+kfueCQfQpkuzyiKXmzFPUt5DtNvn0UUKOnk0sjhFMyZBSmpsdCSG9+wWBrm VIWAmTxLfohOXjjmYi/r8BLmTjoSuBs= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-564-nLkDxvAQP3Ko2L2rSk7nxg-1; Fri, 09 Sep 2022 12:02:22 -0400 X-MC-Unique: nLkDxvAQP3Ko2L2rSk7nxg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A2B1E3817A76; Fri, 9 Sep 2022 16:02:22 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 62DD4492C3B; Fri, 9 Sep 2022 16:02:22 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 289G2JG11598622 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 9 Sep 2022 18:02:20 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 289G2ICC1598621; Fri, 9 Sep 2022 18:02:18 +0200 Date: Fri, 9 Sep 2022 18:02:18 +0200 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches Subject: Re: [Patch] libgomp: Add reverse-offload splay tree Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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 Fri, Aug 26, 2022 at 01:15:24PM +0200, Tobias Burnus wrote: > For reverse-offload data handling, we need to support: > (a) device fn addr -> host fn address > (b) finding already mapped host -> device vars via their device address > > For (a), the functions addrs, we need some extra code (cf. previous patches) > as this information does not exist already. For (b), the variables, we have > two options: > (i) Do a reverse search on the existing data. That's done in > oacc-mem.c's lookup_dev > and obviously is O(N) as it has to check all nodes. > With the assumption "This is not expected to be a common operation." > is might be still okay. > (ii) Using a second splay tree for the reverse lookup. > > The attached patch prepares for this – but does not yet handle all > locations and is not yet active. The 'devicep->load_image_func' call > depends whether the previous [1/3] patch (cf. below) has been applied > or not. > > (The advantage of the reverse-offload mapping is that 'nowait' is not > permitted and 'target {enter,exit,} data device(anchestor:1)' is neither. > Thus, all 'omp target device(ancestor:1)' mapping done in target_rev > can be undone in the same function - and all others are preexisting.) > > OK for mainline? I'd prefer this going in only when somebody actually uses it, and without the #if 0 parts or /* , rev_lookup ? &rev_target_fn_table : NULL */ Also, I wonder if the reverse splay tree is recreatable from the normal splay tree (or at least until something that results in that no longer be the case) if the reverse splay tree couldn't be created lazily, only when something actually asks for the reverse offload the first time walk the whole normal splay tree and populate from it the reverse one and after that maintain it. Or at least not key whether to populate it on reverse offload being requested, but actually some device(ancestor:1) somewhere. > + /* Likeverse for the reverse lookup device->host for reverse offload. */ Likewise or something else? Jakub