[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 Fri, 2016-09-23 at 18:05 +0800, Peng Fan wrote:
> 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 little
> cores into different cpupools. And now big and little cores are in
> different cpu
> clusters from the hardware[1] I can see. 
Note that this `cpupool-split' thing is meant to be an aid to the user
to quickly put the system in a state that we think it could be a common
or relevant setup.

For instance, cpupools can be used to partition big NUMA system, and we
thought users may be interested in having one pool per NUMA node, so an
helper for doing that quickly (i.e., with just one command) has been

That does not mean that it's the only use of cpupools, nor that it's
the only --or the only sane-- way to use cpupools on NUMA systems...
it's just a speculation, in an attempt to make life easier for users.

In a similar way, if we think that, for instance, creating a 'big pool'
and a 'LITTLE pool' would be something common, and/or we (Peng?
Stefano?) already have an usecase for this, we can well implement a
`cpupool-split' variant that does that.

*BUT* that does not mean that people must use it, or that they can't do
anything else or different with cpupools on ARM! In fact, on a NUMA
system, one can completely ignore `cpupool-numa-split', and create
whatever pools and assign pcpus to them at will. Or she can actually
use `cpupool-numa-split' as a basis, i.e., issue the command, manually
alter the resulting status, by doing some more movement of pcpus among
the pools the command created.

All this to say that, especially when thinking about this
cpupool-split thing, we "only" need to come up with something that we
think makes sense, either to be used as is or as a basis, not to the
one and only way cpupools and big.LITTLE --or ARM in general-- should

In fact:
> I think assigning cores from
> different clusters into one cpupool is not a good idea.
I'd be perfectly fine with this, and with cpupool-split on big.LITTLE
to cut pools around clusters boundaries. But I definitely would not
want to forbid the user to manually shuffle things around, including
ending up in a situation where there are pcpus from different
class/cluster/whatever in the same pool... If that is shooting in his
own foot, then so be it!

Thanks and Regards,
<<This happens because I choose it to happen!>> (Raistlin Majere)
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list



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