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)
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xen.org/xen-devel