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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 22 Sep 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/09/2016 18:31, Stefano Stabellini wrote:
> > On Thu, 22 Sep 2016, Julien Grall wrote:
> > > Hello Peng,
> > > 
> > > On 22/09/16 10:27, Peng Fan wrote:
> > > > On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
> > > > > On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
> > > > > > On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
> > > > > A feature like `xl cpupool-biglittle-split' can still be interesting,
> > > > 
> > > > "cpupool-cluster-split" maybe a better name?
> > > 
> > > You seem to assume that a cluster, from the MPIDR point of view, can only
> > > contain the same set of CPUs. I don't think this is part of the
> > > architecture,
> > > so this may not be true in the future.
> > 
> > Interesting. I also understood that a cluster can only have one kind if
> > cpus. Honestly it would be a little insane for it to be otherwise :-)
> 
> I don't think this is insane (or maybe I am insane :)). Cluster usually
> doesn't share all L2 cache (assuming L1 is local to each core) and L3 cache
> may not be present, so if you move a task from one cluster to another you will
> add latency because the new L2 cache has to be refilled.
> 
> The use case of big.LITTLE is big cores are used for short period of burst and
> little core are used for the rest (e.g listening audio, fetching mail...). If
> you want to reduce latency when switch between big and little CPUs, you may
> want to put them within the same cluster.
> 
> Also, as mentioned in another thread, you may have a platform with the same
> micro-architecture (e.g Cortex A-53) but different silicon implementation (e.g
> to have a different frequency, power efficiency). Here the concept of
> big.LITTLE is more blurred.

Different frequency is fine, we have been able to set per core frequency
on x86 cpus for a long time now. If they are cores of the same
micro-architecture, it doesn't matter the cpu frequency, we can deal
with them as usual.

To me big.LITTLE means: it is technically possible, but very difficult
(currently unimplemented), and slower than than usual to move a vcpu
across big and LITTLE pcpus. That's why they need to be dealt with in a
different way.

If we had big.LITTLE cores in the same cluster, sharing L2 caches, with
the same cache line sizes, maybe we could also deal with them as usual
because it wouldn't be much of an issue to migrate a vcpu across big and
LITTLE cores. If/when we come across such an architecture we'll deal
with it.


> That's why I am quite reluctant to name (even if it may be more handy to the
> user) "big" and "little" the different CPU set.
 
Technically you might be right, but "big.LITTLE" is how the architecture
has been advertized to people, so unfortunately we are stuck with the
name. We have to deal with it in those terms at least at the xl level.
Of course in Xen we are free to do whatever we want.

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