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?
