On 29/03/2019 15:09, Juergen Gross wrote: > Make sure the number of vcpus is always a multiple of the scheduling > granularity. Note that we don't support a scheduling granularity above > one on ARM.
I'm afraid that I don't think this is a clever move. In turn, this brings into question the approach to idle handling. Firstly, with a proposed socket granularity, this would be 128 on some systems which exist today. Furthermore, consider the case where cpupool0 has a granularity of 1, and a second pool has a granularity of 2. A domain can be created with an odd number of vcpus and operate in pool0 fine, but can't now be moved to pool1. If at all possible, I think it would be better to try and reuse the idle cpus for holes like this. Seeing as you've been playing with this code a lot, what is your assessment? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
