[PATCH v4 2/2] arm: prefer PSCI for SMP bringup
Dave Martin
dave.martin at linaro.org
Tue Apr 9 08:21:45 EDT 2013
On Tue, Apr 02, 2013 at 12:11:25PM -0400, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
>
> > On Mon, 1 Apr 2013, Nicolas Pitre wrote:
> > > On Mon, 1 Apr 2013, Stefano Stabellini wrote:
> > > > What are the platforms that are going to use smp_init? Do we know how do
> > > > they intend to use it?
> > >
> > > VExpress for one. When booting on a big.LITTLE system such as TC2 on
> > > VExpress, the MCPM layer needs to arbitrate power management operations
> > > on a per cluster basis. In that case there is a MCPM specific set of
> > > SMP ops to be used, even if it may end up calling into PSCI.
> > >
> > > But the important point is that we don't know beforehand what to use,
> > > especially with a kernel that can boot on multiple different VExpress
> > > configurations. The decision has to be made at run time, and therefore
> > > a static default or mdesc->smp ops doesn't cut it.
> >
> > I certainly like the principle and I am in favor of anything that moves
> > the decisions at runtime. I have pulled the patch in the series, it's
> > going to be in the next version.
> >
> > However I am concerned that these platform specific operations won't
> > work with Xen at all.
> > I am getting increasingly certain that we need a Xen specific check in
> > setup_arch to bump up of the priority of PSCI over anything else if Xen
> > is running.
>
> I'm concerned about mixing big.LITTLE and Xen as well. I don't think
> this is going to make an easy match. KVM might have an easier fit here.
>
> But, in any case, even if the MCPM layer gets involved, if Xen is there
> then PSCI will end up being the ultimate interface anyway.
Note that big.LITTLE != MCPM. Virtualisation hosts might be large multi-
cluster systems, but the CPUs might be all of the same type. MCPM or
similar would me needed for the multi-cluster power management even
though there is no big.LITTLE mix of CPUs.
> But let's cross that bridge when we get to it. For now this is still a
> non existing problem.
That's a big open question. Either the host or hypervisor needs to be
very clever about scheduling guests, or you need to bind each guest virtual
CPU to a specific class of physical CPUs -- so, for example you provide
a guest with an explicit mix of bigs and littles.
All we can say about that for now is that it's a potential research area...
Cheers
---Dave
More information about the linux-arm-kernel
mailing list