[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 23/09/16 11:05, Peng Fan wrote:
On Fri, Sep 23, 2016 at 10:24:37AM +0100, Julien Grall wrote:
Hello Peng,

On 23/09/16 03:14, Peng Fan wrote:
On Thu, Sep 22, 2016 at 07:54:02PM +0100, 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.

That is possible that in one cluster, different pcpus runs with different cpu
frequency. This depends on hardware design. Some may require all the cores in
one cluster runs at the same frequency, some may have more complicated design 
supports different cores runs at different frequency.

This is just like you have a smp system, but different cores can run at
different cpu frequency. I think this is not what bit.LITTLE means.

big.LITTLE is a generic term to have "power hungry and powerful core
powerful" (big) with slower and battery-saving cores (LITTLE).

It is not mandatory to have different micro-architectures between big and
LITTLE cores.

In any case, the interface should not be big.LITTLE specific. We don't want
to tie us to one specific architecture.

If all the cores have the same micro-architecture, but for some reason,
they are put in different clusters or cpus in one cluster support running
at different cpu freq.

We still can introduce cpupool-cluster-split or as Juergen suggested,
use "cpupool-slit feature=xx"  to split the cluster or cpuclasses
into different cpupools. This is just a feature that better to have, I think.

The reason to include cpupool-cluster-split or else is to split the big and 
cores into different cpupools. And now big and little cores are in different cpu
clusters from the hardware[1] I can see. I think assigning cores from
different clusters into one cpupool is not a good idea.

I have no idea about future hardware.

If cluster is not prefered, cpuclass maybe a choice, but I personally perfer
"cluster" split for ARM.


[1] https://en.wikipedia.org/wiki/ARM_big.LITTLE

Let me be clear here, the ARM ARM is authoritative not Wikipedia. The latter will only reflect what is done today, not what could be done.

If the ARM ARM does not forbid it, nothing prevent a semiconductor to do it. I gave an example on the mail you answered.

Please try to have a think on all the use case and not only yours.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.