From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id B760F395C02A for ; Thu, 8 Dec 2022 14:35:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B760F395C02A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.96,227,1665475200"; d="scan'208";a="88978780" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 08 Dec 2022 06:35:44 -0800 IronPort-SDR: F0pgWfthwf9aXgTF6/lyL45AAfVCn8bQ5+S8C4Vsw8Y2FDYV1D2U6jkLZiOvrMxa653o9VQ2/S +y8Wsb5nCeBQgGZ5S8CHGOgYfPnkV3xZDWSLuHsbC4z11hOiUmgMA7sYkc3Nt+R0yE3OHaCbEy Fy768WzAK7vZJ98GNZ/fQ3TaGTIVwYNU4CMKdKGV77y1iD9xLQZMgTg3gZVuagj7yjoMSvQudG G+OMq6pszbFii8AzWQGoL+zES4sB0B+OnlSyRB5ggAiFTmaXtNM3NR0PC0u6lqYi7O9c2KcGGZ M1w= Message-ID: Date: Thu, 8 Dec 2022 14:35:36 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH 02/17] libgomp: pinned memory Content-Language: en-GB To: Tobias Burnus , Jakub Jelinek , Thomas Schwinge CC: References: From: Andrew Stubbs In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP 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 08/12/2022 14:02, Tobias Burnus wrote: > On 08.12.22 13:51, Andrew Stubbs wrote: >> On 08/12/2022 12:11, Jakub Jelinek wrote: >>> On Thu, Jul 07, 2022 at 11:34:33AM +0100, Andrew Stubbs wrote: >>>> Implement the OpenMP pinned memory trait on Linux hosts using the mlock >>>> syscall.  Pinned allocations are performed using mmap, not malloc, >>>> to ensure >>>> that they can be unpinned safely when freed. >>> As I said before, I think the pinned memory is too precious to waste >>> it this >>> way, we should handle the -> pinned case through memkind_create_fixed on >>> mmap + mlock area, that way we can create even quite small pinned >>> allocations. >> >> This has been delayed due to other priorities, but our current plan is >> to switch to using cudaHostAlloc, when available, but we can certainly >> use memkind_create_fixed for the fallback case (including amdgcn). > > With available, I assume that nvptx is an 'available device' (per OpenMP > definition, finally added in TR11), i.e. there is an image for nvptx and > - after omp_requires filtering - there remains at least one nvptx device. If plugin-nvptx has been loaded then the function will be available. Do we need to get fancier than that? Andrew