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

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



Hello Peng,

On 22/09/16 10:45, Peng Fan wrote:
On Wed, Sep 21, 2016 at 11:15:35AM +0100, Julien Grall wrote:
Hello Peng,

On 21/09/16 09:38, Peng Fan wrote:
On Tue, Sep 20, 2016 at 01:17:04PM -0700, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Julien Grall wrote:
On 20/09/2016 20:09, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Julien Grall wrote:
On 20/09/2016 12:27, George Dunlap wrote:
On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan <van.freenix@xxxxxxxxx>
wrote:
On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Dario Faggioli wrote:
It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot cpu,
and utilize the second cluster only when the user demands it.

Why do you think the boot CPU will usually be a big one? In the case of Juno
platform it is configurable, and the boot CPU is a little core on r2 by
default.

In any case, what we care about is differentiate between two set of CPUs. I
don't think Xen should care about migrating a guest vCPU between big and
LITTLE cpus. So I am not sure why we would want to know that.

No, it is not about migrating (at least yet). It is about giving useful
information to the user. It would be nice if the user had to choose
between "big" and "LITTLE" rather than "class 0x1" and "class 0x100", or
even "A7" or "A15".

As Dario mentioned in previous email,
for dom0 provide like this:

dom0_vcpus_big = 4
dom0_vcpus_little = 2

to dom0.

If these two no provided, we could let dom0 runs on big pcpus or big.little.
Anyway this is not the important point for dom0 only big or big.little.

For domU, provide "vcpus.big" and "vcpus.little" in xl configuration file.
Such as:

vcpus.big = 2
vcpus.litle = 4


According to George's comments,
Then, I think we could use affinity to restrict little vcpus be scheduled on 
little vcpus,
and restrict big vcpus on big vcpus. Seems no need to consider soft affinity, 
use hard
affinity is to handle this.

We may need to provide some interface to let xl can get the information such as
big.little or smp. if it is big.little, which is big and which is little.

For how to differentiate cpus, I am looking the linaro eas cpu topology code,
The code has not been upstreamed (:, but merged into google android kernel.
I only plan to take some necessary code, such as device tree parse and
cpu topology build, because we only need to know the computing capacity of each 
pcpu.

Some doc about eas piece, including dts node examples:
https://git.linaro.org/arm/eas/kernel.git/blob/refs/heads/lsk-v4.4-eas-v5.2:/Documentation/devicetree/bindings/scheduler/sched-energy-costs.txt

I am reluctant to take any non-upstreamed bindings in Xen. There is a similar
series going on the lklm [1].

For how to differentiate cpu classes, how about directly use
compatible property of each cpu node?

What do you mean by cpu classes? If it is power, then the compatible will not help here. You may have a platform with the same core (e.g cortex A53) but different silicon implementation, so the power efficiency will be different.

Regards,

--
Julien Grall

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

 


Rackspace

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