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 from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
