From: Julien Grall <julien.grall@arm.com>
To: Peng Fan <van.freenix@gmail.com>
Cc: Juergen Gross <jgross@suse.com>, Peng Fan <peng.fan@nxp.com>,
Stefano Stabellini <sstabellini@kernel.org>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Dario Faggioli <dario.faggioli@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [RFC 0/5] xen/arm: support big.little SoC
Date: Thu, 22 Sep 2016 12:21:00 +0100 [thread overview]
Message-ID: <39725915-4e3f-2271-9185-7e4d0b5629fc@arm.com> (raw)
In-Reply-To: <20160922094521.GB22134@linux-u7w5.ap.freescale.net>
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@gmail.com>
>>>>>>>> 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@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-22 11:21 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 2:08 [RFC 0/5] xen/arm: support big.little SoC van.freenix
2016-09-19 2:08 ` [RFC 1/5] xen/arm: domain_build: setting opt_dom0_max_vcpus according to cpupool0 info van.freenix
2016-09-19 2:08 ` [RFC 2/5] xen: cpupool: introduce cpupool_arch_info van.freenix
2016-09-19 2:08 ` [RFC 3/5] xen: cpupool: add arch cpupool hook van.freenix
2016-09-19 2:08 ` [RFC 4/5] xen/arm: move vpidr from arch_domain to arch_vcpu van.freenix
2016-09-19 2:08 ` [RFC 5/5] xen/arm: cpupool: implement arch_domain_cpupool_compatible van.freenix
2016-09-19 8:09 ` [RFC 0/5] xen/arm: support big.little SoC Julien Grall
2016-09-19 8:36 ` Peng Fan
2016-09-19 8:53 ` Julien Grall
2016-09-19 9:38 ` Peng Fan
2016-09-19 9:59 ` Julien Grall
2016-09-19 13:15 ` Peng Fan
2016-09-19 20:56 ` Stefano Stabellini
2016-09-19 9:45 ` George Dunlap
2016-09-19 10:06 ` Julien Grall
2016-09-19 10:23 ` Juergen Gross
2016-09-19 17:18 ` Dario Faggioli
2016-09-19 21:03 ` Stefano Stabellini
2016-09-19 22:55 ` Dario Faggioli
2016-09-20 0:01 ` Stefano Stabellini
2016-09-20 0:54 ` Dario Faggioli
2016-09-20 10:03 ` Peng Fan
2016-09-20 10:27 ` George Dunlap
2016-09-20 15:34 ` Julien Grall
2016-09-20 17:24 ` Dario Faggioli
2016-09-20 19:09 ` Stefano Stabellini
2016-09-20 19:41 ` Julien Grall
2016-09-20 20:17 ` Stefano Stabellini
2016-09-21 8:38 ` Peng Fan
2016-09-21 9:22 ` George Dunlap
2016-09-21 12:35 ` Peng Fan
2016-09-21 15:00 ` Dario Faggioli
2016-09-21 10:15 ` Julien Grall
2016-09-21 12:28 ` Peng Fan
2016-09-21 15:06 ` Dario Faggioli
2016-09-22 9:45 ` Peng Fan
2016-09-22 11:21 ` Julien Grall [this message]
2016-09-23 2:38 ` Peng Fan
2016-09-21 10:09 ` Julien Grall
2016-09-21 10:22 ` George Dunlap
2016-09-21 13:06 ` Julien Grall
2016-09-21 15:45 ` Dario Faggioli
2016-09-21 19:28 ` Julien Grall
2016-09-22 6:16 ` Peng Fan
2016-09-22 8:43 ` Dario Faggioli
2016-09-22 11:24 ` Julien Grall
2016-09-22 16:31 ` Dario Faggioli
2016-09-23 13:56 ` Julien Grall
2016-09-21 18:13 ` Stefano Stabellini
2016-09-21 19:11 ` Julien Grall
2016-09-21 19:21 ` Julien Grall
2016-09-21 23:45 ` Stefano Stabellini
2016-09-22 6:49 ` Peng Fan
2016-09-22 8:50 ` Dario Faggioli
2016-09-22 9:27 ` Peng Fan
2016-09-22 9:51 ` George Dunlap
2016-09-22 10:09 ` Peng Fan
2016-09-22 10:39 ` Dario Faggioli
2016-09-22 10:13 ` Juergen Gross
2016-09-22 9:52 ` Dario Faggioli
2016-09-22 11:29 ` Julien Grall
2016-09-22 17:31 ` Stefano Stabellini
2016-09-22 18:54 ` Julien Grall
2016-09-23 2:14 ` Peng Fan
2016-09-23 9:24 ` Julien Grall
2016-09-23 10:05 ` Peng Fan
2016-09-23 10:15 ` Julien Grall
2016-09-23 13:36 ` Dario Faggioli
2016-09-24 1:57 ` Stefano Stabellini
2016-09-23 13:52 ` Dario Faggioli
2016-09-24 1:35 ` Stefano Stabellini
2016-09-23 2:03 ` Peng Fan
2016-09-22 10:05 ` Peng Fan
2016-09-22 16:26 ` Dario Faggioli
2016-09-22 17:33 ` Stefano Stabellini
2016-09-21 12:38 ` Peng Fan
2016-09-21 9:45 ` Dario Faggioli
2016-09-20 10:18 ` George Dunlap
2016-09-19 20:55 ` Stefano Stabellini
2016-09-19 10:33 ` George Dunlap
2016-09-19 13:33 ` Peng Fan
2016-09-20 0:11 ` Dario Faggioli
2016-09-20 6:18 ` Peng Fan
2016-09-19 16:43 ` Dario Faggioli
2016-09-19 13:08 ` Peng Fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39725915-4e3f-2271-9185-7e4d0b5629fc@arm.com \
--to=julien.grall@arm.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=peng.fan@nxp.com \
--cc=sstabellini@kernel.org \
--cc=van.freenix@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).