From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100604 invoked by alias); 9 Mar 2017 15:24:34 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 100405 invoked by uid 89); 9 Mar 2017 15:24:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=degrees, Knights, knights, depicts X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-pf0-f193.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=H2jikEerJ0cQ9Tjl1hszbgGjbg8IxNimdAPL65/FKMM=; b=p0aECueiBnXGCNo6Ynjx6tT0txKChUzPLhIf9BPC39ULC/PjB/gNXutW+nZ9rsX8Ah /DYGccChowArHhp5znpnoH6BklamQZCTs2CaHI2UfeD3s9LmbkbvVfR57jwIemg/A+Xz 1rA/99wz+EGzPsWJhB1Qx5MdYKC+oz4hakNrA/rOSu64lhfFV3CY231VbYscZAI2tQbU Fv+jQJu2k29gNj5+nXw/FPlRs9/VqXjhXZkXO0dfegcTG2ki2/W9lityOG8tFuqgzgpJ ib9N5m3ZRwTGOwaIBkDvKdHuliSMsRh5D/QUXh75INPRVfiDXP69Rhlq0iYMUF7nHd6U iSCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=H2jikEerJ0cQ9Tjl1hszbgGjbg8IxNimdAPL65/FKMM=; b=houtQw141W7+lQZqDKVUT4y0RWARYB6gdiUDFOfp/k7pmbiI/1Y6B+1gIyxFX99PHM my2oMPA/9LLC4by1zLg1SfkDHuVvAR1WsQ19LZF8M+A96I3UZtLrMyvkEsgY7qaeOdfB DpIFIWKf0iy9OkbZHY+TKQA781R98vqUUiw4WRK/CmuzOX0lsdX0YspEzZ2LZ2EUuKz2 rLdCo8vMb7VkIe2SrBjZlZ4p5GXDqUjZhXDcaoe4LAJHjIzw+bgiEkUy2CMrJeI1jD9C z0vKuoSJ/YGpwxbVGcpQwviGYKd4t6ogQNDaZoDQv4NRkSVr1ISr1k8dTrMDzxTJCeB1 DRCg== X-Gm-Message-State: AMke39mP2k9DaPx+XD5EjHpmbfrCJamhmMHQtKqTXaDcU2Jsb4vc7iEkHIk41bMsnjQDFQ== X-Received: by 10.84.225.22 with SMTP id t22mr18099246plj.14.1489073041576; Thu, 09 Mar 2017 07:24:01 -0800 (PST) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: ABI support for special memory area References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> To: "H.J. Lu" Cc: Carlos O'Donell , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170308-3, 08-03-2017), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2017-q1/txt/msg00014.txt.bz2 H.J, I think we are full 180 degrees out-of-phase in our discussion this time somehow :-) As I have already asked, I want to know what is that ONE-FIXED-FORM of __gnu_mbind_setup being called by ld.so. The code you provided seems to be of Intel's implementation of libmbind. I am interested in how it looks like in ld.so. Because that is what we want to document in the ABI support. We do not want implementation specific details in GNU-gABI. So inside ld.so, would it be what I showed in my earlier mail or would it be something else? In my opinion, we have to bring that out in the ABI support proposal. Without the actual signature/prototype, __gnu_mbind_setup sounds more like a guideline and less like a ABI spec/standard. And in actual code (in ld.so), it may eventually appear really different for each vendor/implementation. So, either keep it as a guideline or make it generic. IMHO, we can not keep the following (original text) as generic: --- > Run-time support > > int __gnu_mbind_setup (unsigned int type, void *addr, size_t length); --- -- Supra On 07-Mar-2017 04:05 AM, H.J. Lu wrote: > On Mon, Mar 6, 2017 at 5:25 AM, Suprateeka R Hegde > wrote: >> On 04-Mar-2017 07:37 AM, Carlos O'Donell wrote: >>> >>> On 03/03/2017 11:00 AM, H.J. Lu wrote: >>>> >>>> __gnu_mbind_setup is called from ld.so. Since there is only one ld.so, >>>> it needs to know what to pass to __gnu_mbind_setup. Not all arguments >>>> have to be used by all implementations nor all memory types. >>> >>> >>> I think what Supra is suggesting is a pointer-to-implementation interface >>> which would allow ld.so to pass completely different arguments to the >>> library depending on what kind of memory is being defined by the sh_info >>> value. It avoids needing to encode all the types in the API, and just >>> uses an incomplete pointer to the type. >> >> >> Thats absolutely right. >> >> However, I am not suggesting one is better over the other. I just want to >> get clarity on how the code looks like for different implementations. >> >> On 03-Mar-2017 09:30 PM, H.J. Lu wrote: >>> >>> __gnu_mbind_setup is called from ld.so. Since there is only one ld.so, >>> it needs to know what to pass to __gnu_mbind_setup. >> >> >> So I want to know what is that ONE-FIXED-FORM of __gnu_mbind_setup being >> called by ld.so. >> >>> Not all arguments >>> have to be used by all implementations nor all memory types. >> >> >> I think I am still not getting this. Really sorry for that. Would it be >> possible for you to write a small pseudo code that depicts how this design >> looks like for different implementations? >> > > For my usage, I only want to know memory type, address and its size: > > #define _GNU_SOURCE > #include > #include > #include > #include > #include > #include > #include > > #ifdef LIBMBIND_DEBUG > #include > #endif > > /* High-Bandwidth Memory node mask. */ > static struct bitmask *hbw_node_mask; > > /* Initialize High-Bandwidth Memory node mask. This must be called before > __gnu_mbind_setup. */ > static void > __attribute__ ((used, constructor)) > init_node_mask (void) > { > if (__get_cpuid_max (0, 0) == 0) > return; > > /* Check if vendor is Intel. */ > uint32_t eax, ebx, ecx, edx; > __cpuid (0, eax, ebx, ecx, edx); > if (!(ebx == 0x756e6547 && ecx == 0x6c65746e && edx == 0x49656e69)) > return; > > /* Get family and model. */ > uint32_t model; > uint32_t family; > __cpuid (1, eax, ebx, ecx, edx); > family = (eax >> 8) & 0x0f; > if (family != 0x6) > return; > model = (eax >> 4) & 0x0f; > model += (eax >> 12) & 0xf0; > > /* Check for KNL and KNM. */ > switch (model) > { > default: > return; > > case 0x57: /* Knights Landing. */ > case 0x85: /* Knights Mill. */ > break; > } > > /* Check if NUMA configuration is supported. */ > int nodes_num = numa_num_configured_nodes (); > if (nodes_num < 2) > return; > > /* Get MCDRAM NUMA nodes. */ > struct bitmask *node_mask = numa_allocate_nodemask (); > struct bitmask *node_cpu = numa_allocate_cpumask (); > > int i; > for (i = 0; i < nodes_num; i++) > { > numa_node_to_cpus (i, node_cpu); > /* NUMA node without CPU is MCDRAM node. */ > if (numa_bitmask_weight (node_cpu) == 0) > numa_bitmask_setbit (node_mask, i); > } > > if (numa_bitmask_weight (node_mask) != 0) > { > /* On Knights Landing and Knights Mill, MCDRAM is High-Bandwidth > Memory. */ > hbw_node_mask = node_mask; > } > else > numa_bitmask_free (node_mask); > numa_bitmask_free (node_cpu); > } > > /* Support all different memory types. */ > > static int > mbind_setup (unsigned int type, void *addr, size_t length, > unsigned int mode, unsigned int flags) > { > int err = ENXIO; > > switch (type) > { > default: > #ifdef LIBMBIND_DEBUG > printf ("Unsupported mbind type %d: from %p of size %p\n", > type, addr, length); > #endif > return EINVAL; > > case GNU_MBIND_HBW: > if (hbw_node_mask) > err = mbind (addr, length, mode, hbw_node_mask->maskp, > hbw_node_mask->size, flags); > break; > } > > if (err < 0) > err = errno; > > #ifdef LIBMBIND_DEBUG > printf ("Mbind type %d: from %p of size %p\n", type, addr, length); > #endif > > return err; > } > > int > __gnu_mbind_setup (unsigned int type, void *addr, size_t length) > { > return mbind_setup (type, addr, length, MPOL_BIND, MPOL_MF_MOVE); > } > > If other memory types need additional information, they can be > passed to __gnu_mbind_setup. We just need to know what > information is needed. > >