Hello, On Fri, Dec 6, 2024 at 12:02 PM Mattias Rönnblom <hof...@lysator.liu.se> wrote: > > On 2024-12-05 18:57, David Marchand wrote: > > As I had reported in rc2, the lcore variables allocation have a > > noticeable impact on applications consuming DPDK, even when such > > applications does not use DPDK, or use features associated to > > some lcore variables. > > > > While the amount has been reduced in a rush before rc2, > > there are still cases when the increased memory footprint is noticed > > like in scaling tests. > > See https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2090931 > > > > What this bug report fails to mention is that it only affects > applications using locked memory.
- By locked memory, are you referring to mlock() and friends? No ovsdb binary calls them, only the datapath cares about mlocking. - At a minimum, I understand the lcore var change introduced an increase in memory of 4kB * 128 (getpagesize() * RTE_MAX_LCORES), since lcore_var_alloc() calls memset() of the lcore var size, for every lcore. In this unit test where 1000 processes are kept alive in parallel, this means memory consumption increased by 512k * 1000, so ~500M at least. This amount of memory is probably significant in a resource-restrained env like a (Ubuntu) CI. - I went and traced this unit tests on my laptop by monitoring kmem:mm_page_alloc, though there may be a better metrics when it comes to memory consumption. # dir=build; perf stat -e kmem:mm_page_alloc -- tests/testsuite -C $dir/tests AUTOTEST_PATH=$dir/utilities:$dir/vswitchd:$dir/ovsdb:$dir/vtep:$dir/tests:$dir/ipsec:: 2154 Which gives: - 1 635 489 kmem:mm_page_alloc for v23.11 - 5 777 043 kmem:mm_page_alloc for v24.11 There is a 4M difference, where I would expect 128k. So something more happens, than a simple page allocation per lcore, though I fail to understand what. Btw, just focusing on lcore var, I did two more tests: - 1 606 998 kmem:mm_page_alloc for v24.11 + revert all lcore var changes. - 1 634 606 kmem:mm_page_alloc for v24.11 + current series with postponed allocations. -- David Marchand
