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

[Julien Grall <julien.grall@arm.com>]

Hi George,

On 19/09/2016 11:45, George Dunlap wrote:
> On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall <julien.grall@arm.com> wrote:
>>>> As mentioned in the mail you pointed above, this series is not enough to
>>>> make
>>>> big.LITTLE working on then. Xen is always using the boot CPU to detect
>>>> the
>>>> list of features. With big.LITTLE features may not be the same.
>>>>
>>>> And I would prefer to see Xen supporting big.LITTLE correctly before
>>>> beginning to think to expose big.LITTLE to the userspace (via cpupool)
>>>> automatically.
>>>
>>>
>>> Do you mean vcpus be scheduled between big and little cpus freely?
>>
>>
>> By supporting big.LITTLE correctly I meant Xen thinks that all the cores has
>> the same set of features. So the feature detection is only done the boot
>> CPU. See processor_setup for instance...
>>
>> Moving vCPUs between big and little cores would be a hard task (cache line
>> issue, and possibly feature) and I don't expect to ever cross this in Xen.
>> However, I am expecting to see big.LITTLE exposed to the guest (i.e having
>> big and little vCPUs).
>
> So it sounds like the big and LITTLE cores are architecturally
> different enough that software must be aware of which one it's running
> on?

That's correct. Each big and LITTLE cores may have different errata, 
different features...

It has also the advantage to let the guest dealing itself with its own 
power efficiency without introducing a specific Xen interface.

>
> Exposing varying numbers of big and LITTLE vcpus to guests seems like
> a sensible approach.  But at the moment cpupools only allow a domain
> to be in exactly one pool -- meaning if we use cpupools to control the
> big.LITTLE placement, you won't be *able* to have guests with both big
> and LITTLE vcpus.
>
>>> If need to create all the pools, need to decided how many pools need to be
>>> created.
>>> I thought about this, but I do not come out a good idea.
>>>
>>> The cpupool0 is defined in xen/common/cpupool.c, if need to create many
>>> pools,
>>> need to alloc cpupools dynamically when booting. I would not like to
>>> change a
>>> lot to common code.
>>
>>
>> Why? We should avoid to choose a specific design just because the common
>> code does not allow you to do it without heavy change.
>>
>> We never came across the big.LITTLE problem on x86, so it is normal to
>> modify the code.
>
> Julien is correct; there's no reason we couldn't have a default
> multiple pools on boot.
>
>>> The implementation in this patchset I think is an easy way to let Big and
>>> Little
>>> CPUs all run.
>>
>>
>> I care about having a design allowing an easy use of big.LITTLE on Xen. Your
>> solution requires the administrator to know the underlying platform and
>> create the pool.
>>
>> In the solution I suggested, the pools would be created by Xen (and the info
>> exposed to the userspace for the admin).
>
> FWIW another approach could be the one taken by "xl
> cpupool-numa-split": you could have "xl cpupool-bigLITTLE-split" or
> something that would automatically set up the pools.
>
> But expanding the schedulers to know about different classes of cpus,
> and having vcpus specified as running only on specific types of pcpus,
> seems like a more flexible approach.

So, if I understand correctly, you would not recommend to extend the 
number of CPU pool per domain, correct?

Regards,

-- 
Julien Grall

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