On Fri, Jul 05, 2024 at 02:18:30AM +0000, Zhang, Rui wrote: > > > > I have a doubt about this, won't the future Intel multi-die > > > > systems > > > > have die-scope for the RAPL PMU like Casecadelake-AP? > > > > > > For future multi-die systems that I know, the RAPL is still package > > > scope > > > > I think in that case we can go with rule 2, it would be future proof > > for Intel systems. If you agree, I can make the change in next > > version. > > > > Something like below?, > > > > -#define rapl_pmu_is_pkg_scope() \ > > - (boot_cpu_data.x86_vendor == X86_VENDOR_AMD || > > \ > > > > > > - boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) > > > > +#define rapl_pmu_is_die_scope() \ > > + (boot_cpu_data.x86_model_id == CASCADELAKE) > > > sounds good to me. Just a reminder that using boot_cpu_data.vfm is a > better choice here. > > And it would be great to get Peter' view on this.
Peter is confused :-) So you're saying that: - old Intel is pkg wide (it has no DIE enumeration) - Cascadelake (part of the skylake refresh) is per-DIE - modern Intel is pkg wide (they have no DIE enumeration) - future Intel will be pkg wide And this works because for everything that does not enumerate a specific DIE topology, it ends up begin the same as the PKG topology. But what about future products that have DIE but are not CASCADE (what about COOPERLAKE) ? If this really is a one off for CASCADE, then yes, I think we should be doing what Dhananjay suggests, and then the PKG naming is fine.
