Hi,
On 01/03/2018 08:29 AM, Sudeep Holla wrote:
On 02/01/18 02:29, Xiongfeng Wang wrote:
Hi,
On 2017/12/18 20:42, Morten Rasmussen wrote:
On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
Hi,
On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
[+Morten, Dietmar]
$SUBJECT should be:
arm64: topology: rename cluster_id
[cut]
I think we still need the information describing which cores are in one
cluster. Many arm64 chips have the architecture core/cluster/socket. Cores
in one cluster may share a same L2 cache. That information can be used to
build the sched_domain. If we put cores in one cluster in one sched_domain,
the performance will be better.(please see kernel/sched/topology.c:1197,
cpu_coregroup_mask() uses 'core_sibling' to build a multi-core
sched_domain).
We get all the cache information from DT/ACPI PPTT(mainly topology) and now
even the geometry. So ideally, the sharing information must come from that.
Any other solution might end up in conflict if DT/PPTT and that mismatch.
So I think we still need variable to record which cores are in one
sched_domain for future use.
I tend to say no, at-least not as is.
Well, either way, with DynamiQ (and a55/a75) the cores have private
L2's, which means that the cluster sharing is happening at what is then
the L3 level. So, the code I had in earlier versions would have needed
tweaks to deal with that anyway.
IMHO, if we want to detect this kind of sharing for future scheduling
domains, it should probably be done independent of PPTT/DT/MIPDR by
picking out shared cache levels from struct cacheinfo *. Which makes
that change unrelated to the basic population of cacheinfo and
cpu_topology in this patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
