On Thu, May 25, 2017 at 10:24:46PM -0500, Christoph Lameter wrote: > 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. Sure, i can get that to you. The question remains: Are you arguing its not valid for a realtime application to use any system call which changes a vmstat counter? Because if they are allowed, then its obvious something like this is needed. > Then please rerun the test by setting the vmstat_interval to 60. > > Do another run with your modifications and show the difference. Will do so. > > > 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>
