From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 278223858D3C for ; Wed, 29 Jun 2022 12:24:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 278223858D3C 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.92,231,1650960000"; d="scan'208";a="77915608" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 29 Jun 2022 04:24:29 -0800 IronPort-SDR: 2Wng9iwnbUqBoRm77ZFZuPr6K28n8DrnMUppU/odk3052u5cu6FLRk4z/lqK0TlfsO1WOo1lN8 0mMz8DbxtSSamxkrOoUEzsX+Ka84Hj/KfWXqTw9kzCMp7FQ4DDUWUGkhQOWYCXDsT6yu0Z6kzQ n5U5ljfk7ZCM15xB/qlaxl6Bhgw+Mz8u7XjGVpePc7ewbXnDV1s3o9gR9WHtlji14tESgm24iD cfwchjXipzUWfDFoRf2TQutIrLPO38KoTumPqOqPxGlZ9FEx/5a9QQSuxjs1fz7FhdaIgq7RmL y4M= Message-ID: <6dade46f-826a-8520-6abb-5635ec8f2262@codesourcery.com> Date: Wed, 29 Jun 2022 13:24:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library Content-Language: en-GB To: Jakub Jelinek CC: References: From: Andrew Stubbs In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: , X-List-Received-Date: Wed, 29 Jun 2022 12:24:33 -0000 On 29/06/2022 11:45, Jakub Jelinek wrote: > And omp_init_allocator needs to decide what to do if one asks for features > that need memkind as well as for features that need whatever you/Abid have > been working on. A possible resolution is punt (return omp_null_allocator), > or prefer one feature over the other one or vice versa. > From the features currently handled by memkind, even before my changes for > consistency with libomp from llvm omp_high_bw_mem_space was considered a > hard request, ditto omp_atk_pinned omp_atv_true, but the rest was just taken > as optimization hint. Right now I'm rebasing our patches so that they build and pass our tests again. I don't know what to do if someone requests pinned high-bandwidth memory. I don't even know if that's a thing that can exist. Right now, as I have my dev branch, the high-bandwidth will take precedence simply because memkind is checked first. I presume that if memkind ever grew the ability to allocate pinned memory you would still have the choose one "kind" or the other. Andrew