[lng-odp] [PATCH v1 1/1] linux-gen: ishm: don't initialize anonymous mappings

2018-09-10 Thread Github ODP bot
From: Josep Puigdemont Anonymous mappings are automatically initalized to zero. >From the mmap manual: "MAP_ANONYMOUS: The mapping is not backed by any file; its contents are initialized to zero." Signed-off-by: Josep Puigdemont --- /** Email created from pull request 695

[lng-odp] [PATCH v1 0/1] linux-gen: ishm: don't initialize anonymous mappings

2018-09-10 Thread Github ODP bot
Anonymous mappings are automatically initalized to zero. >From the mmap manual: "MAP_ANONYMOUS: The mapping is not backed by any file; its contents are initialized to zero." Signed-off-by: Josep Puigdemont josep.puigdem...@linaro.org github /** Email

[lng-odp] [PATCH v4 0/2] linux-gen: ishm: implement huge page cache

2018-09-10 Thread Github ODP bot
With this patch, ODP will pre-allocate several huge pages at init time. When memory is to be mapped into a huge page, one that was pre-allocated will be used, if available, this way ODP won't have to trap into the kernel to allocate huge pages. The idea with this implementation is to trick ishm

[lng-odp] [PATCH v4 1/2] linux-gen: ishm: implement huge page cache

2018-09-10 Thread Github ODP bot
From: Josep Puigdemont With this patch, ODP will pre-allocate several huge pages at init time. When memory is to be mapped into a huge page, one that was pre-allocated will be used, if available, this way ODP won't have to trap into the kernel to allocate huge pages. The idea with this

[lng-odp] [PATCH v4 2/2] linux-gen: ishm: make huge page cache size dynamic

2018-09-10 Thread Github ODP bot
From: Josep Puigdemont Signed-off-by: Josep Puigdemont --- /** Email created from pull request 685 (joseppc:fix/cache_huge_pages) ** https://github.com/Linaro/odp/pull/685 ** Patch: https://github.com/Linaro/odp/pull/685.patch ** Base sha: 6d48d7f7f684b8aa87f7eb4f922d45be345ed771 ** Merge

[lng-odp] [PATCH v2 1/1] linux-generic : fix wrong spelling

2018-09-10 Thread Github ODP bot
From: Seungha Son Signed-off-by: Seungha Son --- /** Email created from pull request 696 (linuxias:master) ** https://github.com/Linaro/odp/pull/696 ** Patch: https://github.com/Linaro/odp/pull/696.patch ** Base sha: 6d48d7f7f684b8aa87f7eb4f922d45be345ed771 ** Merge commit sha:

[lng-odp] [PATCH v2 0/1] linux-generic : fix wrong spelling

2018-09-10 Thread Github ODP bot
Signed-off-by: Seungha Son linux...@gmail.com github /** Email created from pull request 696 (linuxias:master) ** https://github.com/Linaro/odp/pull/696 ** Patch: https://github.com/Linaro/odp/pull/696.patch ** Base sha:

[lng-odp] [Linaro/odp] 464606: linux-gen: sysinfo: return 0 if hugepages are not ...

2018-09-10 Thread GitHub
Branch: refs/heads/master Home: https://github.com/Linaro/odp Commit: 4646069f0417fc180977100af2bc1f527b2d4f28 https://github.com/Linaro/odp/commit/4646069f0417fc180977100af2bc1f527b2d4f28 Author: Dmitry Eremin-Solenikov Date: 2018-09-10 (Mon, 10 Sep 2018) Changed paths:

[lng-odp] ODP crash at buffer_alloc_multi() while inserting into iplookuptable

2018-09-10 Thread gyanesh patra
Hi, ODP is crashing at buffer_alloc_multi() while inserting into iplookuptable. The backtrace is as below: (gdb) bt #0 buffer_alloc_multi (pool=0x7fffd5420c00, buf_hdr=buf_hdr@entry=0x7fff55fa8bb0, max_num=max_num@entry=1) at odp_pool.c:700 #1 0x00433083 in odp_buffer_alloc

Re: [lng-odp] ODP crash at buffer_alloc_multi() while inserting into iplookuptable

2018-09-10 Thread Maxim Uvarov
do you have some test code to reproduce it? On 10 September 2018 at 18:06, gyanesh patra wrote: > Hi, > ODP is crashing at buffer_alloc_multi() while inserting into iplookuptable. > > The backtrace is as below: (gdb) bt #0 buffer_alloc_multi > (pool=0x7fffd5420c00,

Re: [lng-odp] ODP crash at buffer_alloc_multi() while inserting into iplookuptable

2018-09-10 Thread Maxim Uvarov
Can you please compile ODP with debug: ./configure --enable-debug --enable-debug-print --enable-helper-debug-print CFLAGS="-O0" Do you run on x86? It looks like prefix_insert_into_lx() a little bit buggy and there might be recursion forever. Ret is defined as uint8, has to be int. e->cidr does