Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Wed, 2016-12-07 at 12:21 -0800, Stefano Stabellini wrote:
> On Tue, 6 Dec 2016, Dario Faggioli wrote:
> > E.g., if I have pCPU 0 loaded at 75% and pCPU 1 loaded at 25%, vCPU
> > A
> > has a lot of routed interrupts, and moving it gives me perfect load
> > balancing (i.e., load will become 50% on pCPU 0 and 50% on pCPU 1)
> > should I move it or not?
> > Well, it depends if whether or not we think that the overhead we
> > save
> > by not migrating outweights the benefit of a perfectly balanced
> > system.
> 
> Right. I don't know where to draw the line. I don't how much weight
> it
> should have, but certainly it shouldn't be considered the same thing
> as
> moving any other vCPU.
>
Right. As I said, Credit2 load balancer is nice and easy to extend
already --and needs to become nicer and easier to extend in order to
deal with soft-affinity, so I'll work on that soon (there's patches out
for soft-affinity which does sort of something like that, but I'm not
entirely satisfied of them, so I'll probably rework that part).

At that point, I'll be more than happy to consider this, and try to
reason about how much it should be weighted. After all, the only thing
we need to take this information into account when making load
balancing decisions is a mechanism for knowing how many of these routed
interrupt a vCPU has, and of course this needs to be:
 - easy to use,
 - super quick (load balancing is an hot path),
 - architecture independent,

is this the case already? :-)

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
https://lists.xen.org/xen-devel