On 01/30/2017 01:48 PM, Lee, Chunghan wrote:
Hi Billy,
Thank you for the reply.
I can understand the experiment condition clearly.
*/>[[BO'M]] This is a valid suggestion and is worth investigating. I
would like to use linux tracing tools such as perf to see when or if
the pmd thread in/**//*
*/>testpmd is de-scheculed and if so for how long. Actually I’d start
by checking this on the testpmd thread on the host – as this removes
any doubt about/**//*
*/>timestamp accuracy on VMs./*
Very good!
Actually, I have another suggestion
to control CPU allocation for testpmd using taskset.
In this time, we can observe the latency of
process scheduling, and compare their pattern with the outlier.
If the latency has a similar pattern,
it would be a major cause of the outlier.
Hi,
I am not sure I have completely understood this discussion, but you can
also isolate some cores with a boot parameter and then assign the pmd
task to those core. The Linux kernel will not schedule any work on
isolated cores, but it allows to pin processes to them. The kernel can
also run rcu callbacks on the pmd cores which can mess up the
measurements. RCU callbacks can also be turned off with a boot parameter
(https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt).
Finally, you can have System Management Interrupts (SMIs) on the
hardware. There is not so much you can do with these but at least you
can notice them by reading the tsc counter. I have written a little
program do do that (https://github.com/nokia/clocktick_jumps).
-Tapio
_______________________________________________
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
