On 13/09/17 00:13, Thomas Monjalon wrote:
12/09/2017 22:29, Aaron Conole:
Thomas Monjalon <tho...@monjalon.net> writes:
12/09/2017 16:50, Aaron Conole:
Eelco Chaudron <echau...@redhat.com> writes:
Call the mlockall() function, to attempt to lock all of its process
memory into physical RAM, and preventing the kernel from paging any
of its memory to disk.
When using testpmd for performance testing, depending on the code path
taken, we see a couple of page faults in a row. These faults effect
the overall drop-rate of testpmd. On Linux the mlockall() call will
prefault all the pages of testpmd (and the DPDK libraries if linked
dynamically), even without LD_BIND_NOW.
Signed-off-by: Eelco Chaudron <echau...@redhat.com>
Acked-by: Aaron Conole <acon...@redhat.com>
It is interesting, but why make it in testpmd?
Maybe it should be documented in this guide:
http://dpdk.org/doc/guides/linux_gsg/nic_perf_intel_platform.html
Well, I'm not sure what the user would be able to do to get the
prefaulting performance without having a library they use with
LD_PRELOAD and a function with the constructor attribute which does the
same thing, AND export LD_BIND_NOW before linking starts.
The LD_BIND_NOW simply does the symbol resolution, but there's no
guarantee that it will fault all the code pages in to process space, and
without an mlockall(), I'm not sure that there's any kind of guarantee
that they don't get swapped out of resident memory (which also leads to
later page faults).
Maybe I misunderstood the question?
Maybe you misunderstood :)
I was saying that if this improvement applies to applications,
it should be documented in the tuning guide.
I'll try to find a good place in the documentation for adding a
reference to mlockall(), but will send it as a separate documentation patch.
//Eelco
