On Thu, 25 May 2017, Marcelo Tosatti wrote: > Argument? We're showing you the data that this is causing a latency > problem for us. Sorry I am not sure where the data shows a latency problem. There are interrupts and scheduler ticks. But what does this have to do with vmstat? Show me your dpdk code running and trace the tick on / off events as well as the vmstat invocations. Also show all system calls occurring on the cpu that runs dpdk. That is necessary to see what triggers vmstat and how the system reacts to the changes to the differentials. Then please rerun the test by setting the vmstat_interval to 60. Do another run with your modifications and show the difference. > > Something that crossed my mind was to add a new tunable to set > > the vmstat_interval for each CPU, this way we could essentially > > disable it to the CPUs where DPDK is running. What's the implications > > of doing this besides not getting up to date stats in /proc/vmstat > > (which I still have to confirm would be OK)? Can this break anything > > in the kernel for example? > > Well, you get incorrect statistics. The statistics are never completely accurate. You will get less accurate statistics but they will be correct. The differentials may not be reflected in the counts shown via /proc but there is a cap on how inaccurate those can becore. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
