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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 19 Sep 2016, Dario Faggioli wrote:
> On Mon, 2016-09-19 at 12:23 +0200, Juergen Gross wrote:
> > On 19/09/16 12:06, Julien Grall wrote:
> > > On 19/09/2016 11:45, George Dunlap wrote:
> > > > But expanding the schedulers to know about different classes of
> > > > cpus,
> > > > and having vcpus specified as running only on specific types of
> > > > pcpus,
> > > > seems like a more flexible approach.
> > > 
> > > So, if I understand correctly, you would not recommend to extend
> > > the
> > > number of CPU pool per domain, correct?
> > 
> > Before deciding in which direction to go (multiple cpupools, sub-
> > pools,
> > kind of implicit cpu pinning) 
> >
> You mention "implicit pinning" here, and I'd like to stress this,
> because basically no one (else) in the conversation seem to have
> considered it. In fact, it may not necessarily be the best long term
> solution, but doing something based on pinning is, IMO, a very
> convenient first step (and may well become one of the 'modes' available
> to the user for taking advantage of big.LITTLE.
> 
> So, if cpus 0-3 are big and cpus 4,5 are LITTLE, we can:
>  - for domain X, which wants to run only on big cores, pin all it's
>    vcpus to pcpus 0-3
>  - for domain Y, which wants to run only on LITTLE cores, pin all it's
>    vcpus to pcpus 4,5
>  - for domain Z, which wants its vcpus 0,1 to run on big cores, and
>    it's vcpus 2,3 to run on LITTLE cores, pin vcpus 0,1 to pcpus 0-3, 
>    and pin vcpus 2,3 to pcpus 4,5
> 
> Setting thing up like this, even automatically, either in hypervisor or
> toolstack, is basically already possible (with all the good and bad
> aspects of pinning, of course).
> 
> Then, sure (as I said when replying to George), we may want things to
> be more flexible, and we also probably want to be on the safe side --if 
> ever some components manages to undo our automatic pinning-- wrt the
> scheduler not picking up work for the wrong architecture... But still
> I'm a bit surprised this did not came up... Julien, Peng, is that
> because you think this is not doable for any reason I'm missing?

Let's suppose that Xen detects big.LITTLE and pins dom0 vcpus to big
automatically. How can the user know that she really needs to be careful
in the way she pins the vcpus of new VMs? Xen would also need to pin
automatically vcpus of new VMs to either big or LITTLE cores, or xl
would have to do it.

The whole process would be more explicit and obvious if we used
cpupools. It would be easier for users to know what it is going on --
they just need to issue an `xl cpupool-list' command and they would see
two clearly named pools (something like big-pool and LITTLE-pool). We
wouldn't have to pin vcpus to cpus automatically in Xen or xl, which
doesn't sound like fun.

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