Re: [PATCH 1/2] x86,sched: Add support for frequency invariance
From: Giovanni Gherdovich
Date: Wed Oct 02 2019 - 08:20:29 EST
Hello Peter,
late replies as I wasn't in the office last week.
On Tue, 2019-09-24 at 18:30 +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2019 at 04:42:15AM +0200, Giovanni Gherdovich wrote:
> > +static const struct x86_cpu_id has_turbo_ratio_group_limits[] = {
> > + ICPU(INTEL_FAM6_ATOM_GOLDMONT),
> > + ICPU(INTEL_FAM6_ATOM_GOLDMONT_X),
>
> That's GOLDMONT_D in recent tip kernels.
Right, I saw that now.
>
> > + ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS),
> > + ICPU(INTEL_FAM6_SKYLAKE_X),
>
> What about KABYLAKE_X and ICELAKE_X ?
KABYLAKE_X: does it exist? I couldn't find it in
arch/x86/include/asm/intel-family.h (the tip tree), I only see KABYLAKE_L and
KABYLAKE.
ICELAKE_X: well, I don't know really. Does this model have the same semantic
for MSR_TURBO_RATIO_LIMIT as SKYLAKE_X (which is family = 0x6, model = 0x55)?
This is for Len B. and Srinivas P. (in CC).
The latest Software Developer's Manual (SDM) from May 2019 (volume 4, section
2.17.3, "MSRs Specific to Intel Xeon Processor Scalable Family") mentions only
"CPUID DisplayFamily_DisplayModel = 06_55H", which is SKYLAKE_X, as having the
semantic I'm looking for here (in addition to Atom Goldmont's).
The semantic I'm referring to is that MSR_TURBO_RATIO_LIMIT doesn't contain
turbo levels for the fixed group sizes 1-2-3-4-... cores, the group sizes are
specified in a different MSR (and could be 2-4-8-12-... for example).
If the SDM is outdated and ICELAKE_X is also in that category, then the
turbostat source code is outdated too as it has this function to detect this
feature:
int has_turbo_ratio_group_limits(int family, int model)
{
if (!genuine_intel)
return 0;
switch (model) {
case INTEL_FAM6_ATOM_GOLDMONT:
case INTEL_FAM6_SKYLAKE_X:
case INTEL_FAM6_ATOM_GOLDMONT_X:
return 1;
}
return 0;
}
(from the tree lenb/linux.git, branch "turbostat", turbostat version 19.08.31
not yet merged into mainline)
Giovanni