file: lib/librte_eal/common/malloc_heap.c function: malloc_heap_alloc_on_heap_id code snippet: if (!alloc_more_mem_on_socket(heap, size, socket_id, flags, align, bound, contig)) { ret = heap_alloc(heap, type, size, flags, align, bound, contig); /* this should have succeeded */ if (ret == NULL) RTE_LOG(ERR, EAL, "Error allocating from heap\n"); } alloc_more_mem_on_socket takes more than 500ms when numa node0 runs out of memory. our program has 64 threads which all can get memory from dpdk(hugepagesz=1G). our business code can not go well with such code snippet, so we remove alloc_more_mem_on_socket in malloc_heap_alloc_on_heap_id, we test it more than 1 month, and it runs ok so, is there any side effect when i remove alloc_more_mem_on_socket in malloc_heap_alloc_on_heap_id?
my program need about 100G hugepage, so we need get memory from numa node0 and node1
Since your application has been running for 1+ month without allocating memory from node#1(as a result of removing alloc_more_mem_on_socket), why do you think your program requires 100G memory? cross-numa memory access is definitely costly than local memory.
If cross-numa memory is really needed, why not use the legacy memory mode, other than the dynamic memory mode, to hide the allocation cost from runtime? For the two memory modes, refere to: https://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html
If memory is constrained, Jerin's patch may be helpful, could you check how memory interleaving is working on your SoC? http://patches.dpdk.org/patch/64012/
ok, i gonna take a look at this patch
Looks like the patch referred to in comment #4 was superseded by another version. And ultimately applied to the tree after some modifications. Can you check if the issue is addressed now? Thanks Ajit commit 3f2d6766e3a620a166ee868dfde324e6a1e4b7f3 Author: Jerin Jacob <jerinj@marvell.com> Date: Wed Jan 15 02:36:03 2020 +0530 mempool: remove memory wastage on non-x86