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

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>,
	Steve Capper <Steve.Capper@arm.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Punit Agrawal <punit.agrawal@arm.com>,
	George Dunlap <george.dunlap@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: Fri, 23 Sep 2016 10:24:37 +0100	[thread overview]
Message-ID: <98f090ef-3fff-304d-6fb7-d4f9da858a0a@arm.com> (raw)
In-Reply-To: <20160923021423.GC27908@linux-u7w5.ap.freescale.net>

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 that
> 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.

Regards,

-- 
Julien Grall

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