Re: numa_alloc_onnode does not allocate on node passed as argument

Andres Nötzli <[email protected]> Thu, 30 Oct 2014 16:21:11 -0700
Newsgroups org.kernel.vger.linux-numa
Message-ID <[email protected]>
Hi Elena,

Thank you so much for looking into this issue. It is good to hear that =
you are getting the same strange result.

I posted the output of /proc/pid/numa_maps here: https://gist.github.co=
m/4tXJ7f/5e89f466e29cd1f7f1aa

I hope this helps.

Thanks again,
Andres

> On 29 Oct 2014, at 21:33, Elena Ufimtseva <[email protected]> wrote=
:
>=20
> Hello Andres
>=20
> I looked at the example you gave, had multiple variations running and
> have same strange results.
> The default local policy should be in use when there is no other poli=
cy defined.
> The only thing what comes to my mind its the shared library libnuma
> which has its data on different node then the node I try to run
> the test process on.
> Can you take a look and check what node is used by libnuma in
> /proc/pid/numa_maps?
>=20
> I will keep searching for an answer, its rather interesting topic.
> Or maybe someone else will give more details on this.
>=20
> Thank you!
>=20
>=20
> On Thu, Oct 23, 2014 at 1:17 PM, Andres N=C3=B6tzli <noetzli@stanford=
=2Eedu> wrote:
>> Hi Elena,
>>=20
>> That would be great! I created a gist with the kernel config (cat /b=
oot/config-$(uname -r)): https://gist.github.com/4tXJ7f/408a562abe5d4f2=
8656d
>>=20
>> Please let me know if you need anything else.
>>=20
>> Thank you very much,
>> Andres
>>=20
>>> On 23 Oct 2014, at 06:15, Elena Ufimtseva <[email protected]> wro=
te:
>>>=20
>>> Hi Andres
>>>=20
>>> I will poke around this on the weekend on my NUMA machine.
>>> Can you also attach your kernel config please?
>>>=20
>>> Thank you.
>>>=20
>>> On Wed, Oct 22, 2014 at 12:40 PM, Andres N=C3=B6tzli <noetzli@stanf=
ord.edu> wrote:
>>>> Hi Elena,
>>>>=20
>>>> Thank you very much for your quick reply! numa_set_strict(1) and n=
uma_set_strict(0) both result in the wrong output. I did not change the=
 default policy.
>>>>=20
>>>> numa_get_membind returns 1 for all nodes before and after numa_run=
_on_node.
>>>> numa_get_interleave_mask returns 0 for all nodes.
>>>> numa_get_run_node_mask is all 1s before and 0010 after numa_run_on=
_node.
>>>>=20
>>>> The machine config (the CPUs are all Intel(R) Xeon(R) CPU E5-4657L=
 v2 @ 2.40GHz):
>>>>=20
>>>> $ numactl --hardware
>>>> available: 4 nodes (0-3)
>>>> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 48 49 50 51 52 53 54 55 56 =
57 58 59
>>>> node 0 size: 262093 MB
>>>> node 0 free: 966 MB
>>>> node 1 cpus: 12 13 14 15 16 17 18 19 20 21 22 23 60 61 62 63 64 65=
 66 67 68 69 70 71
>>>> node 1 size: 262144 MB
>>>> node 1 free: 82 MB
>>>> node 2 cpus: 24 25 26 27 28 29 30 31 32 33 34 35 72 73 74 75 76 77=
 78 79 80 81 82 83
>>>> node 2 size: 262144 MB
>>>> node 2 free: 102 MB
>>>> node 3 cpus: 36 37 38 39 40 41 42 43 44 45 46 47 84 85 86 87 88 89=
 90 91 92 93 94 95
>>>> node 3 size: 262144 MB
>>>> node 3 free: 113 MB
>>>> node distances:
>>>> node   0   1   2   3
>>>> 0:  10  20  30  20
>>>> 1:  20  10  20  30
>>>> 2:  30  20  10  20
>>>> 3:  20  30  20  10
>>>>=20
>>>> Thanks again,
>>>> Andres
>>>>=20
>>>>> On 22 Oct 2014, at 06:12, Elena Ufimtseva <[email protected]> w=
rote:
>>>>>=20
>>>>> On Tue, Oct 21, 2014 at 11:47 PM, Andres N=C3=B6tzli <noetzli@sta=
nford.edu> wrote:
>>>>>> Hi everyone,
>>>>>>=20
>>>>>> I am experiencing a weird problem. When using numa_alloc_onnode =
repeatedly to allocate memory, it does not allocate memory on the node =
passed as an argument.
>>>>>>=20
>>>>>> Sample code:
>>>>>> #include <numa.h>
>>>>>> #include <numaif.h>
>>>>>> #include <iostream>
>>>>>> using namespace std;
>>>>>>=20
>>>>>> void find_memory_node_for_addr(void* ptr) {
>>>>>> int numa_node =3D -1;
>>>>>> if(get_mempolicy(&numa_node, NULL, 0, ptr, MPOL_F_NODE | MPOL_F_=
ADDR) < 0)
>>>>>>    cout << "WARNING: get_mempolicy failed" << endl;
>>>>>> cout << numa_node << endl;
>>>>>> }
>>>>>>=20
>>>>>> int main() {
>>>>>> int64_t* x;
>>>>>> int64_t n =3D 5000;
>>>>>> //numa_set_preferred(1);
>>>>>>=20
>>>>>> numa_run_on_node(2);
>>>>>> for(int i =3D 0; i < 20; i++) {
>>>>>>    size_t s =3D n * sizeof(int64_t);
>>>>>>    x =3D (int64_t*)numa_alloc_onnode(s, 1);
>>>>>>    for(int j =3D 0; j < n; j++)
>>>>>>       x[j] =3D j + i;
>>>>>>    find_memory_node_for_addr(x);
>>>>>> }
>>>>>>=20
>>>>>> return 0;
>>>>>> }
>>>>>>=20
>>>>>> Output:
>>>>>> 1
>>>>>> 1
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>> 1
>>>>>> 2
>>>>>>=20
>>>>>> When uncommenting the line "numa_set_preferred(1);=E2=80=9D, the=
 output is all 1s as expected. Am I doing something wrong? Have you see=
n similar issues?
>>>>>>=20
>>>>>> I am running Ubuntu 12.04.5 LTS:
>>>>>> $ cat /proc/version
>>>>>> Linux version 3.2.0-29-generic (buildd@allspice) (gcc version 4.=
6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #46-Ubuntu SMP Fri Jul 27 17:03:23=
 UTC 2012
>>>>>>=20
>>>>>> I am using libnuma 2.0.10 but I=E2=80=99ve had the same problem =
with 2.0.8~rc3-1.
>>>>>>=20
>>>>>> Thank you very much,
>>>>>> Andres
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-=
numa" in
>>>>>> the body of a message to [email protected]
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.ht=
ml
>>>>>=20
>>>>> Hi Andres
>>>>>=20
>>>>> Can you try to use strict policy by calling numa_set_strict?
>>>>>=20
>>>>> If you comment out setting the preferred node, the default policy=
 is
>>>>> in action (I assume you did no change it, not for the process, no=
t
>>>>> system wide) which is preferred also.
>>>>> But here you set preferred to a specific node and manual says, th=
e
>>>>> default for process is to allocate on the node it runs.
>>>>> So I wonder what is the cpu affinity for this process looks like.=
=2E.
>>>>> Also maybe just to confirm you can check the policy from within y=
our
>>>>> running code?
>>>>>=20
>>>>> Can you also post the machine NUMA config?
>>>>>=20
>>>>> --
>>>>> Elena
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Elena
>>=20
>>=20
>=20
>=20
>=20
> --=20
> Elena