On 2024-11-08 23:13, Thomas Monjalon wrote:
08/11/2024 20:53, Morten Brørup:
From: Morten Brørup [mailto:m...@smartsharesystems.com]
Sent: Friday, 8 November 2024 19.35
From: David Marchand [mailto:david.march...@redhat.com]
Sent: Friday, 8 November 2024 19.18
OVS locks all pages to avoid page faults while processing packets.
It sounds smart, so I just took a look at how it does this. I'm not sure, but
it seems like it only locks pages that are actually mapped (current and future).
1M for each lcore translates to allocating 128M with default build
options on x86.
This resulted in OOM while running unit tests in parallel.
Is the root cause the lcore variables library itself, or the unit test using a
lot of memory for testing the lcore variables?
We don't want to fix the library if the problem is elsewhere.
The fix works for our urgent issue and we want to make a release candidate soon.
At the moment, the more demanding DPDK user of lcore variable is
rte_service, with a 2112 bytes object.
Limit the lcore variable maximum size to 4k which looks more
reasonable.
4 KB is not future proof.
Here's an example where 16 KB is cutting it close:
https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35E9F7D0@smart
server.smartshare.dk/
Depends on how we are going to use it. 4 KB suffices if we only want to
use it for "small" structures.
This is what is stated in the doc:
"Lcore variables are suitable for small objects"
"The amount of data kept in lcore variables is projected to be small"
>>> Would 64 KB work as a compromise?
Let's consider based on the need.
The lcore variables are new and we don't want it to degrade the DPDK footprint,
at least not in this first version.
4 KB is a memory page on common systems,
it looks reasonnable and big enough for a "variable".
Applied, thanks.
Why do you have maintainers if you just ignore them?
