Re: [Xen-devel] [PATCH] xen: credit1: on vCPU wakeup, kick away current only if makes sense

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Mon, 2015-11-02 at 12:03 +0000, George Dunlap wrote:
> On 29/10/15 10:57, Dario Faggioli wrote:

> > In particular, 1) has been reported to cause the following
> > issue:
> > 
> >  * VM-IO: 1-vCPU pinned to a pCPU, running netperf
> >  * VM-CPU: 1-vCPU pinned the the same pCPU, running a busy
> >            CPU loop
> >  ==> Only VM-I/O: throughput is 806.64 Mbps
> >  ==> VM-I/O + VM-CPU: throughput is 166.50 Mbps
> > 
> > This patch solves (for the above scenario) the problem
> > by checking whether or not it makes sense to try to
> > migrate away the vCPU currently running on the processor.
> > In fact, if there aren't idle processors where such a vCPU
> > can execute. attempting the migration is just futile
> > (harmful, actually!).
> > 
> > With this patch, in the above configuration, results are:
> > 
> >  ==> Only VM-I/O: throughput is 807.18 Mbps
> >  ==> VM-I/O + VM-CPU: throughput is 731.66 Mbps
> > 
> > Reported-by: Kun Suo <ksuo@xxxxxxxx>
> > Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> > Tested-by: Kun Suo <ksuo@xxxxxxxx>
> 
> I'm getting a bit worried about how long the path is to actually wake
> up
> a vcpu; if this only affected the "pin" case, then I might say it
> wasn't
> worth it.  
>
Same here. That's why I started looking at a solution that was more
general that the pinned scenario, for which it wasn't worth adding
complexity in the wakeup path.

I've got a patch for that almost ready (avoiding boosting in case of
wakeups induced by a migration).

However, while working on that, I realized...

> But it looks to me like this could be a consistent pattern on
> any system where there was consistently no idlers available; so at
> this
> point it's probably better to have than not:
> 
...exactly this. I.e., it's not only the pinned case. Even 'free' 
vCPUs, or vCPUs with arbitrary large affinities, if the system is busy,
can incur into this sort of spurious migration attempts, with takes
time (migrate-->pick-->wake-->tickle-->rescheduling), and yet leaves
the situation unchanged (with the fix I'm preparing; without, it causes
the reported anomaly).

At that point, this, and the boosting after migration, became two
orthogonal issues, both needing fixing. :-/

> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>
Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel