On Wed, Feb 20, 2019 at 10:08:48AM -0500, Len Brown wrote:

Thanks for the comments, Peter. I'll update the patch to address the
syntax points.  (Maybe checkpatch.pl should be updated to reflect your
preferences?).

Don't know about checkpatch; I ignore plenty of its output. I think tglx
started a document somewhere for what tip prefers, but I'm not sure
where that went.

About macros vs C.  I agree with your preference.
I used macros to be consistent with the existing code, and to be as
backport friendly as possible.
(a number of distros need to pull these patches into their supported kernels)
Sure, I'm willing to write in a cosmetic-only patch, after the
functional changes are upstream.

Fair enough.

quoted

It would've been nice to have the CPUID instruction 1F leaf reference
3B-3.9 in the SDM, and maybe mention this here too.

I didn't mention SDM sections because they change -- leaving stale
pointers in our commit messages.  The SDM is re-published 4 times per
year.

Yah, I know. Which is why I keep all SDMs. So if you say, book 3 section
8 of Jul'17, I can find it :-)

quoted

You haven't explained, and I can't readily find it in the SDM either,
how these topology bits relate to caches and interconnects.

Will these die thingies share LLC, or will LLC be per die. Will NUMA
span dies or not.

Excellent question.
Cache enumeration in Leaf-4 is totally unchanged.
ACPI NUMA tables are totally unchanged.

Sure; and yet Sub-NUMA-Clustering broke stuff in interesting ways. I'm
trying to get a feel for how these levels will interact with all that.

Before that SNC stuff, caches had never spanned NODEs (and I still
think that is 'creative' at best).

From a scheduler point of view, imagine that a SKX system with 4 die
in 4 packages was mechanically re-designed so that those 4 die resided
in 2 double-sized packages.

They may have tweaked the links between the die, but logically it is
identical and compatible, and the legacy kernel will function
properly.

This example has LLC in die and yes that works.

But I can imagine things like L2 in tile and L3 across tiles but within
DIE and then it _might_ make sense to still consider the tile for
scheduling.

Another option is having the LLC off die; also not unheard of.

And then there's many creative and slightly crazy ways this can all be
combined :/

So the effect of Leaf B,1F is that it defines the scope of MSRs.  eg.
what processors does a die-scope MSR cover.  That is why the rest of
the patch is about sysfs topology, and about package MSR scope.

Yes, there will be more exotic MSR situations in future products --
the first ones are pretty simple -- something  called a
package-scope-MSR  in the SDM today becomes a die-scope-MSR in this
generation on a multi-die/package system.

Yes :-(

It also reflects how many packages appear in sysfs, and this can
effect licensing of some kinds of software.

That's just plain insanity and we should not let that affect our sysfs
interfaces.