[PATCH] arm64: topology: add MPIDR-based detection

[Lorenzo Pieralisi]

On Wed, Jun 04, 2014 at 05:34:00PM +0100, Mark Brown wrote:
> On Wed, Jun 04, 2014 at 04:51:29PM +0100, Lorenzo Pieralisi wrote:
> 
> > My question is: is it better to pack affinity levels and "guess" what aff3
> > (and aff2 on non-SMT) means or add an additional level of hierarchy in the
> > arm64 topology code (eg book_id - implemented only for s390 to the best
> > of my knowledge) ?
> 
> Shoving them in there would address the issue as well, yes (though we'd
> still have to combine aff2 and aff3 for the non-SMT case).  I don't know
> if having books enabled has some overhead we don't want though.
> 
> > I personally prefer the latter approach but I think it boils down to
> > understanding what do we want to provide the scheduler with if we have
> > a hierarchy that extends beyond "cluster" level.
> 
> > I will be glad to help you implement it when time comes (and this will also
> > fix the clusters of clusters DT issue we are facing - ie how to treat them).
> 
> > Now, I do not think it is a major problem at the moment, merging the
> > patch I sent will give us more time to discuss how to define the
> > topology for clusters of clusters, because that's what we are talking
> > about.
> 
> In so far as you're saying that we don't really need to worry about
> exactly how we handle multi-level clusters properly at the minute I
> agree with you - until we have some idea what they physically look like
> and can consider how well that maps onto the scheduler and whatnot it
> doesn't really matter and we can just ignore it.  Given that I'm not
> concerned about just reporting everything as flat like we do with DT at
> the minute and don't see a real need to theorise about it, it'll just be
> a performance problem and not a correctness problem when it is
> encountered.  That feels like a better position to leave things in as it
> will be less stress for whoever is bringing up such a fancy new system,
> they can stand a reasonable chance of getting things at least running
> with minimal effort.

Ok, I think we have an agreement, let's merge the patch I sent and
discuss the way forward to cater for systems with clusters of clusters
when we reasonably expect them to hit production, the scheduler expected
topology might well change by that time and now we are well positioned
to cope with future extensions (and actually packing affinity levels
might well be the final solution if the scheduler expects a "flat"
topology at the higher topology level).

> > Does it make sense ?
> 
> Like I say I do think that merging your current code is better than
> nothing.

Great, thanks for bearing with me.

Thanks !
Lorenzo