On Fri, 19 May 2017 12:13:26 -0500 (CDT) Christoph Lameter <cl@xxxxxxxxx> wrote: > > So why are you against integrating this simple, isolated patch which > > does not affect how current logic works? > > Frankly the argument does not make sense. Vmstat updates occur very > infrequently (probably even less than you IPIs and the other OS stuff that > also causes additional latencies that you seem to be willing to tolerate). Infrequently is not good enough. It only has to happen once to cause a problem. Also, IPIs take a few us, usually less. That's not a problem. In our testing we see the preemption caused by the kworker take 10us or even more. I've never seeing it take 3us. I'm not saying this is not true, I'm saying if this is causing a problem to us it will cause a problem to other people too. > And you can configure the interval of vmstat updates freely.... Set > the vmstat_interval to 60 seconds instead of 2 for a try? Is that rare > enough? No, we'd have to set it high enough to disable it and this will affect all CPUs. 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? -- 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>
