Re: [RFC 0/5] xen/arm: support big.little SoC

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

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

On Mon, 2016-09-19 at 11:33 +0100, George Dunlap wrote:
> On 19/09/16 11:06, Julien Grall wrote:
> > So, if I understand correctly, you would not recommend to extend
> > the
> > number of CPU pool per domain, correct?
> 
> Well imagine trying to set the scheduling parameters, such as weight,
> which in the past have been per-domain.  Now you have to specify
> parameters for a domain in each of the cpupools that its' in.
> 
True, and not really convenient indeed. I think we can think of a way
to shape the interface in such a way that it's not too bad to use
(provide sane defaults/default behavior, etc), but this should be
definitely kept in mind.

In general, I agree with Juergen that, before implementing anything, we
must come up with a design, bearing in mind both behavior and
interface.

(I'll reply in some more details directly to Juergen's email.)

> No, I think it would be a lot simpler to just teach the scheduler
> aboutIf we want to support heterogeneous CPUs, some like this is
> absolutely necessary. In fact, either we set (and enforce) very
> strict rules on cpupools and pinning, or we'd end up scheduling stuff
> built for arch A on a processor of arch B! :-O
> different classes of cpus.  credit1 would probably need to be
> modified
> so that its credit algorithm would be per-class rather than pool-
> wide;
> but credit2 shouldn't need much modification at all, other than to
> make
> sure that a given runqueue doesn't include more than one class; and
> to
> do load-balancing only with runqueues of the same class.
> 
If we want to support heterogeneous CPUs, some like this is absolutely
necessary. In fact, either we set (and enforce) very strict rules on
cpupools and pinning, or we'd end up scheduling stuff built for arch A
on a processor of arch B! :-O

The "strict limits" approach may be an option --and this patch is a
first example of it-- but it's easy to see that it's very inflexible
(cpus can't move between pools, domains can't be migrated, etc). On the
other hand, as soon as we "relax" the constraints a little bit, we
absolutely need to modify the scheduler code to avoid bad things to
happen.

As George is saying, both Credit1 and Credit2 needs to be modified in
order to make sure that a vcpu that is meant to run on a big cpu is not
picked up for being executed by a LITTLE cpu. This has to do with
tweaking the load balancing code in both of them (e.g., in Credit1, a
LITTLE cpu must not steal work from a big cpu). Whether or not it will
also be required to change the Credit-ing algorithm, it will have to be
seen. The effect would be similar to some sort of pinning, which indeed
does not play well with Credit1 accounting logic... but we can probably
see about this along the way (or just focus only con Credit2! :-P)

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