Re: [DOC RFC] Heterogeneous Multi Processing Support in Xen

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2871 bytes --]

On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote:
> On 08/12/16 11:27, Dario Faggioli wrote:
> > On Thu, 2016-12-08 at 07:12 +0100, Juergen Gross wrote:
> > > Any idea how to avoid problems in the schedulers related to vcpus
> > > with
> > > different weights? 
> > > 
> > Sure: use Credit2! :-P
> > 
> > And I'm not joking (not entirely, at least), as the alternative is
> > to
> > re-engineer significantly the algorithm inside Credit, which I'm
> > not
> > sure is doable or worthwhile, especially considering we have
> > alternatives.
> 
> So you really solved the following problem in credit2?
> 
So, pinning will always _affect_ scheduling, that is actually its goal.
And in fact, it really should be used when there is no alternative, or
when the scenario is understood well enough, that its effects are known
(or at least known to be beneficial for the workload running on the
host).

In Credit2, weights used to make a vCPU burn credits faster or slower
than the other vCPUs, while in Credit1, the algorithm is much more
complex. Also, in Credit2, everything is computed per-runqueue. Pinning
of course interferes, but should really be less disruptive than in
Credit1.

All this being said, I was not yet around when you came up with the
idea that pinning was disturbing weighted fairness, so I'm not sure
what the original argument was... I'll go back check the email
conversation in the archive. And again, all the times that one can use
cpupool, that should be the preferred solution, but there are
situations where that's just not suitable, and we need pinning.

This case is a little bit border-line. Sure using pinning is not ideal,
and in fact it's only happening in the initial stages. When actually
modifying the scheduler, we will, in Credit2, do something like having
one runqueue per class (or more, but certainly not any runqueues that
"cross" classes, as that would not work), which puts us in a pretty
decent situation, I think. For Credit, let's see, but I'm afraid we
won't be able to guarantee much more than technical correctness (i.e.,
not scheduling on forbidden classes).

> You have three domains with 2 vcpus each and different weights. Run
> them
> on 3 physical cpus with following pinning:
> 
> dom1: pcpu 1 and 2
> dom2: pcpu 2 and 3
> dom3: pcpu 1 and 3
> 
> How do you decide which vcpu to run on which pcpu for how long?
> 
Ok, it was a public holiday here today, so I did not really have time
to think about this example. And tomorrow I'm on PTO. I'll look closely
on Monday.

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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