On Thu, 2018-01-25 at 16:09 +0000, Andrew Cooper wrote: > On 25/01/18 15:57, Jan Beulich wrote: > > > > > > > For the record, the overwhelming majority of calls to > > __sync_local_execstate() being responsible for the behavior > > come from invalidate_interrupt(), which suggests to me that > > there's a meaningful number of cases where a vCPU is migrated > > to another CPU and then back, without another vCPU having > > run on the original CPU in between. If I'm not wrong with this, > > I have to question why the vCPU is migrated then in the first > > place. > > This is a known (mis)feature of the Credit scheduler. When a PCPU > goes > idle, it aggressively steals work from the adjacent cpus, even if the > adjacent cpu only has a single vcpu to run and is running it. > > XenServer has this gross hack which makes aggregate networking > measurements far far better > > https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/sched-credit > 1-use-per-pcpu-runqueue-count.patch > > Dario made a different fix to Credit1 upstream which was supposed to > resolve this behaviour (although I can't locate the patch by a list > of > titles), but based on these observations, I'd say the misfeature > hasn't > been fixed. > Yes, it's 341450eaf753 ("xen: credit1: increase efficiency and scalability of load balancing."), and that commit and the XenServer patch are functionally equivalent.
So, I'm not convinced about that being the actual cause of the described behaviour. Tracing would be the way to tell (hopefully) for sure. Regards, Dario
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
