Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Dario Faggioli <dfaggioli@xxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel