Hi,

I am interested to know about what 'hwloc_bind'  does beyond malloc()- the
OS call.
If I do like this:

        int mydata=11;
int * mydata_ptr;

*mydata_ptr = (int *)malloc(sizeof(int));  *

* or,*
*       mydata_ptr = (int *) hwloc_alloc (topology, (sizeof(int)));*
*        mydata_ptr = &mydata; *
and then call:
*hwloc_get_area_membind_nodeset (*topology, *mydata_ptr,* sizeof(int),
*nodeset,* &nodepolicy, flags); flags:= 0/1 process / thread

it gives me the all available nodesets.
According to Brice previous reply: hwloc (get_area_membind ) returns once Linux
could have allocated (bound) memory buffer (the physical address I am
sending as *mydata_ptr*).

*Is this something hwloc can only returns locations (& corresponding
nodeset) once it is bound (*set_area_membind*) prior ..? *

Thank you in advance.
- Raju

On Fri, Dec 18, 2015 at 11:57 AM, Rezaul Karim Raju <raju.cse.b...@gmail.com
> wrote:

> Hi Brice,
>
> Thanks for your time and nice explanation.
> I have looked at the issue with location return (the page proportion
> across multiple node & physical allocation). Are you thinking to add this
> function..? Like if we think list of node or nodes where the array is
> allocated (only if physically allocated otherwise NULL) is it possible..?
>
> I am looking for getting the physical location of data allocated by OS
> default policy. Appreciate any better idea and please share with me.
>
> Best Regards,
> - Raju
>
> On Tue, Dec 15, 2015 at 3:28 AM, Brice Goglin <brice.gog...@inria.fr>
> wrote:
>
>>
>>
>> Le 15/12/2015 07:21, Brice Goglin a écrit :
>>
>>
>>
>> Le 15/12/2015 05:57, Rezaul Karim Raju a écrit :
>>
>> *OUTPUT: *
>> *Policy-->* buffer(Array: A) *membind [default OS binding] Policy is:= 1
>> [1 refers to *HWLOC_MEMBIND_FIRSTTOUCH
>> <https://www.open-mpi.org/projects/hwloc/doc/v1.11.1/a00083.php#ggac9764f79505775d06407b40f5e4661e8a979c7aa78dd32780858f30f47a72cca0>
>> *]*
>> *Nodeset --> *buffer(Array: A) bound to nodeset* 0x000000ff *with
>> contains*:*
>>  node #0 (OS index 0) with 8387047424 bytes of memory
>>  node #1 (OS index 1) with 8471617536 bytes of memory
>>  node #2 (OS index 2) with 8471621632 bytes of memory
>>  node #3 (OS index 3) with 8471617536 bytes of memory
>>  node #4 (OS index 4) with 8471621632 bytes of memory
>>  node #5 (OS index 5) with 8471617536 bytes of memory
>>  node #6 (OS index 6) with 8471621632 bytes of memory
>>  node #7 (OS index 7) with 8471564288 bytes of memory
>>
>> *why it shows allocated memory is bound to all available nodeset..?
>> should it not be allocated to a specific nodeset one ..?*
>>
>>
>> Hello
>>
>> You are confusing the "binding" and the "actual location". Your memory
>> buffer isn't bound to a specific location by default. But Linux has to
>> allocate it somewhere. So your buffer is "located" in some node after the
>> allocation, but it is not "bound" there (what get_area_membind returns)
>> which means Linux could have allocated it somewhere else.
>>
>> hwloc cannot currently return the "location" of a memory buffer. I have
>> been thinking about adding this feature in the past, but it looks like you
>> are the first actual user requesting this. We could add something like
>> hwloc_get_last_memory_location(topology, input buffer, outputnodeset)
>> At least on Linux that's possible.
>>
>> For clarity, this is similar to the difference between
>> hwloc_get_cpubind() and hwloc_get_last_cpu_location(): A task always runs
>> on a specific PU, even if it is not bound to anything specific PU.
>>
>>
>> By the way, there is already an issue for this:
>> https://github.com/open-mpi/hwloc/issues/97
>>
>> Feel to comment there.
>>
>> Brice
>>
>>
>> _______________________________________________
>> hwloc-users mailing list
>> hwloc-us...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>> Link to this post:
>> http://www.open-mpi.org/community/lists/hwloc-users/2015/12/1226.php
>>
>
>
>
> --
> ------------------------
> RaJu, Rezaul Karim
> Graduate Student (PhD) | Computer Science | University of Houston
> Research in High Performance Computing Tools
> Houston, Texas-77004
>



-- 
------------------------
RaJu, Rezaul Karim
Graduate Student (PhD) | Computer Science | University of Houston
Research in High Performance Computing Tools
Houston, Texas-77004

Reply via email to